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Abstract 


This  guide  is  intended  for  use  by  General  Services  Administration  staff  or  design  consultants  when 
preparing  specifications  for  interoperable  building  control  systems  using  BACnet  technology.  It 
explains  the  issues  that  need  to  be  considered  when  specifying  the  communication  details  and  makes 
some  recommendations  for  the  choices  involved.  It  is  not  a sample  specification  and  it  does  not 
address  all  issues  important  for  a good  control  system  specification.  The  focus  is  on  specific  issues 
related  to  the  interconnection  and  interoperation  of  building  automation  systems  and  devices  using 
BACnet.  It  is  intended  to  complement  more  general  guidelines  for  direct  digital  control  systems  for 
building  automation  applications. 

Key  words:  BACnet,  building  automation  and  control,  direct  digital  control,  energy  management 
systems,  communication  protocol,  ANSI/ASHRAE  Standard  135 
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1 Purpose  of  this  Guide 


This  document  has  been  produced  for  the  General  Services  Administration  (GSA)  to  foster  a 
broad-based  understanding  and  consistent  application  of  ASHRAE/ANSI  Standard  135-1995 
(BACnet™)  for  automation  systems  in  Federal  buildings  - in  both  new  and  retrofit  construction. 
As  such,  GSA  personnel  and  GSA’s  selected  design  consultants  should  utilize  this  document  as  a 
guide  in  planning,  designing,  procuring  and  managing  projects  involving  Building  Automation 
System  (BAS)  installations,  upgrades,  or  expansions. 

As  used  in  this  guide,  a BAS  is  a network  of  microprocessor-based  devices  that  are  configured  to 
perform  energy  management  and  monitoring,  heating,  ventilating  and  air-conditioning  (HVAC) 
control,  fire  protection,  security,  and/or  related  building  automation  functions.  It  is  the  GSA’s 
goal  to  competitively  procure  BAS  solutions  that  cost-effectively  meet  the  design  objectives  of 
each  project  while  incorporating  a common  BAS  communication  protocol  to  the  greatest  extent 
practicable.  This  then  provides  a foundation  for  non-proprietary  future  enhancements  and 
expansion  at  each  building  - as  well  as  regional/national  intercommunications  and  information 
sharing  across  the  GSA  building  stock.  As  such,  all  BAS  projects  - to  some  reasonable  minimum 
degree  - must  comply  with  the  BACnet  standard. 

It  must  be  stressed  that  this  guide  is  focused  on  the  BACnet  protocol  itself,  considerations  for  its 
inclusion  in  a BAS  design,  and  some  practical  recommendations  to  follow  in  the  various  steps  of 
a project  that  includes  BAS  technology.  This  guide  is  not  intended  to  provide  the  details  of  how 
to  specify  automation  systems  for  a particular  building.  HVAC  applications,  or  other  proiect- 

specific  ftmctions.  Details  concerning  sensors,  actuators,  wiring,  piping,  sequences  of  operation, 
and  general  design  practice  are  outside  the  scope  of  this  document.  This  guide  focuses  on  the 
specific  issues  related  to  the  interconnection  and  interoperation  of  BAS  installations  and  system- 
level  devices  using  BACnet. 

For  information  on  general  BAS  design  issues,  the  reader  is  referred  to  ASHRAE  Guideline  13P, 
Guideline  to  Specifying  DDC  Systems* 1.  In  addition,  any  BAS  design  should  be  prepared  in 
compliance  with  applicable  GSA  guides  for  design  and  specification  of  temperature  control 
systems  (e.g.,  Chapter  5 of  PBS-PQ100.1  “Facilities  Standards”  and  “U.S.  Courts  Design 
Guide”). 

2 Specifying  Interoperable  BACnet  Systems 

BACnet,  ASHRAE’s  Building  Automation  and  Control  Networking  protocol,  was  designed  to 
provide  a single,  uniform  standard  for  building  control  systems.  The  ultimate  goal  of  this 
standardization  effort  was  "interoperability."  Interoperability  means  the  ability  of  disparate 
control  system  devices  to  work  together  toward  a common  objective  through  the  digital 
exchange  of  relevant  information.  Although  interoperability  is  often  thought  of  in  terms  of 
interconnecting  equipment  from  multiple  manufacturers,  it  is  also  possible  to  contemplate 
interoperating  systems  from  a single  vendor,  possibly  equipment  of  different  vintages.  Thus, 
while  BACnet  enables  multivendor  interoperability,  it  in  no  way  requires  it. 


1 Available  from  the  American  Society  of  Heating,  Refrigerating  & Air-Conditioning  Engineers,  Inc.,  Atlanta,  GA. 
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BACnet  also  provides  a rich  variety  of  tools  to  accomplish  its  communication  objectives. 
Because  of  this,  interoperability  depends  on  the  common  selection  of  choices  where  multiple 
techniques  are  provided  to  accomplish  a particular  function.  One  of  this  guide's  primary  goals  is 
to  provide  GSA  specifiers  with  the  information  needed  to  understand  and  make  the  appropriate 
choices. 

The  basic  strategy  for  specifying  interoperable  systems  based  on  BACnet  may  be  summarized  in 
the  following  steps. 

1.  Specify  the  desired  building  automation  and  control  system  functionality.  Specify  the  features 
described  in  the  Interoperability  Areas  defined  below  as  appropriate  to  the  project. 

2.  Specify  the  desired  workstation  functionality.  Specify  the  features  described  in  the 
Interoperability  Areas  defined  below  as  appropriate  to  the  project. 

3.  Specify  the  desired  local  or  wide  area  network  technology  as  appropriate  to  the  project. 

4.  Specify  that  all  networks  shall  make  use  of  the  BACnet  protocol  and  that  all  devices  supplied 
shall  implement  the  BACnet  functionality  enumerated  in  the  device  profiles  in  Annex  B of 
this  document. 

5.  Specify  any  additional  BACnet  functionality  as  recommended  for  specific  requirements  in  this 
document. 

3 Interoperability  Areas 

"Interoperability  areas"  (LAs)  are  intended  to  describe  the  functionality  that  is  important  in 
practical  automation  and  control  systems  to  achieve  specific  operational  objectives.  The  five  IAs 
are:  data  sharing,  alarm  and  event  management,  scheduling,  trending,  and  device  and  network 
management.  Each  LA  implies  a set  of  capabilities.  Each  capability,  in  turn,  requires  that  specific 
elements  of  BACnet  be  implemented  in  a particular  device  to  enable  interoperability  in  a known 
and  predictable  manner  with  a minimum  of  field  engineering.  The  selection  of  which  BACnet 
elements  are  required  for  a particular  type  of  device  - workstation,  building  controller,  or 
application  specific  controller  - is  indicated  in  the  recommended  device  profiles  presented  in 
Annex  B.  This  section  describes  the  specific  capabilities  associated  with  each  LA  and  the 
specification  issues  that  should  be  considered  for  each  LA. 

Note  that  the  original  BACnet  standard  (ANSI/ASHRAE  135-1995)  contained  a clause  that 
attempted  to  facilitate  the  specification  of  BACnet  systems  by  defining  "Conformance  Classes" 
and  "Functional  Groups."  Conformance  Classes  were  a numerical  hierarchy  (1  to  6)  that 
prescribed  an  increasingly  complex  set  of  BACnet  capabilities  intended  to  correspond  to 
increasingly  sophisticated  control  system  devices.  Functional  Groups  were  additional  collections 
of  BACnet  capabilities  thought  to  be  required  to  carry  out  a particular  task.  The  idea  was  that  a 
device  would  be  designed  to  fall  within  a particular  conformance  class  but  that  functional  group 
capabilities  could  be  added  as  deemed  necessary  for  practical  application.  These  concepts,  while 
well-intentioned,  were  flawed  in  that  the  combined  conformance  classes  and  functional  groups 
did  not  correspond  particularly  well  to  real-world  devices  in  the  marketplace.  The  scheme  also 
required  an  undue  amount  of  knowledge  about  the  details  of  the  BACnet  specification  on  the  part 
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of  the  building  control  system  design  community.  For  these  reasons,  a new  approach,  the 
definition  of  broad  areas  in  which  interoperability  is  desired,  has  been  undertaken  and  will  form 
the  basis  of  this  guide. 

This  new  approach  attempts  to  decouple  the  task  of  the  specifying  engineer  from  that  of  the 
control  system  manufacturer.  From  the  perspective  of  the  specifying  engineer,  a BACnet  system 
is  described  in  terms  of  the  desired  building  control  system  functions  without  regard  for,  or  a 
need  to  know  about,  the  underlying  BACnet  capabilities  needed  to  carry  them  out.  These 
functions,  in  turn,  imply  a set  of  BACnet  capabilities  that  manufacturers  can  then  embed  in  each 
of  their  devices  of  a particular  type.  The  specification  of  these  minimum  requirements  is  the 
subject  of  ongoing  work  within  the  ASHRAE  BACnet  committee.  The  mechanism  is  called 
"BACnet  Interoperability  Building  Blocks"  (BIBBs).  These  are  presented  in  Annex  A. 

3.1  Data  Sharing 

"Data  sharing"  is  the  exchange  of  information  between  BACnet  devices.  It  may  be  uni- 
directional or  bi-directional  Interoperability  in  this  area  permits  the  collection  of  data  for 
archival  storage,  graphics,  and  reports,  the  sharing  of  common  sensor  or  calculated  values 
between  devices,  carrying  out  interlocked  control  strategies,  and  the  modification  of  setpoints  or 
other  operational  parameters  of  BACnet  objects. 

3.1.1  Data  Sharing  - Specification  Issues  and  Recommendations 

Point  list 

In  order  for  suppliers  to  size  their  systems  correctly  in  terms  of  their  data  sharing 
capabilities,  a list  of  each  desired  data  point  should  be  provided. 

• Specify  as  part  of  the  fundamental  system  design  each  analog  and  binary  input, 
output,  and  value  which  is  to  be  accessed  over  the  network. 

Presentation  of  data 

Most  data  are  presented  in  the  form  of  tabular  reports,  real-time  graphics,  or  plots  of  data 
values  versus  time. 

• Specify  the  desired  format  of  all  tabular  reports.  Indicate  which  point  values,  or 
sets  of  point  values,  should  be  available  in  a single  report. 

• Specify  which  building  systems  should  be  available  as  graphic  displays.  Specify 
the  desired  update  interval  for  data  on  the  graphics.  Consider  values  of  Is  to  5s. 

• Specify  that  any  data  value  from  any  networked  device  should  be  available  for 
plotting  in  real-time.  (For  the  long-term  archival  storage  of  values,  see  the 
discussion  of  trending  in  3.4)  It  should  be  possible  to  plot  binary  and  analog 
data  concurrently  as  well  as  multiple  instances  of  each  datatype  on  the  same 
screen.  Specify  the  desired  sampling  interval  Fast  processes,  such  as  steam 
valve  operation,  should  allow  rapid  sampling  (Is  to  5s  intervals),  while  slow 
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processes,  such  as  space  temperature  monitoring,  can  be  sampled  infrequently 
(30s  to  60s  intervals).  Alternatively,  if  the  data  reside  in  devices  that  support 
change  of  value  reporting  (see  5.4)  this  mechanism  could  be  specified  in  lieu  of 
a specific  sampling  interval. 

Monitoring  of  any  property  of  any  BACnet  object  type 

It  should  be  possible  to  monitor  any  property  of  any  standard  or  proprietary  BACnet 
object  type. 

• Specify  that  it  must  be  possible  to  read  and  display  the  value  of  any  property, 
including  all  required  properties,  supported  optional  properties,  and  proprietary 
extensions  of  every  object  of  every  networked  device. 


Global  objects 

Some  objects  represent  globally  significant  data.  Examples  are  shared  sensors,  such  as 
used  to  monitor  the  outside  air  temperature,  or  common  binary  information  such  as 
whether  night  setback  is  in  effect. 

• Specify  which  data  are  to  be  shared  and  with  which  devices  or  systems.  For 
each  piece  of  global  information,  specify  the  frequency  of  the  sharing,  e.g.,  once 
a minute,  once  an  hour,  once  a day,  or  upon  change  of  value.  If  change  of  value 
notifications  are  desired,  specify  the  amount  of  change  required  before  a new 
notification  is  transmitted. 

Setpoint  and  parameter  modification 

An  operator  with  sufficient  privilege  should  be  able  to  change  or  "write"  any  desired 
setpoint  or  parameter  in  any  networked  device.  Since  some  devices  may  be  pre- 
configured and  their  operating  parameters  stored  in  non-volatile,  non-writable  memory  it 
is  prudent  to  indicate  which  setpoints  and  parameters  must  be  adjustable  over  the 
network. 


• Specify  which  operating  setpoints  and  parameters,  at  a minimum,  must  be 
available  for  modification  via  BACnet  services  (as  opposed  to  proprietary 
vendor-specific  means). 

• Specify  the  desired  means  of  making  the  modifications,  e.g.,  via  a graphical  user 
interface  (GUI)  (as  opposed  to  having  to  make  a command  line  entry  or 
downloading  a configuration  file). 

Peer-to-Peer  data  exchange 


BACnet  provides  the  capability  for  information  to  be  exchanged  between  networked 
devices  without  operator  involvement.  However,  it  is  important  to  describe  the  required 
functionality  clearly. 
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• Specify  any  required  data  dependencies  (interlocks,  shared  setpoints,  schedules, 
and  so  on)  that  must  be  implemented  via  the  network. 

3.2  Alarm  and  Event  Management 

"Alarm  and  event  management"  is  the  exchange  of  data  between  BACnet  devices  related  to  the 
occurrence  of  a predefined  condition  that  meets  specific  criteria.  Such  conditions  are  called 
"events"  and  may  be  the  basis  for  the  initiation  of  a particular  control  action  in  response  or  the 
simple  logging  of  the  event’s  occurrence.  The  event  may  also  be  deemed  to  represent  a condition 
which  constitutes  an  "alarm"  requiring  human  acknowledgment  and  intervention.  Interoperability 
in  this  area  permits  the  annunciation  and  acknowledgment  of  alarms;  the  display  of  data 
indicating  the  basis  for  the  alarm  annunciation;  the  sharing  of  events  for  the  purpose  of  logging 
or  distributed  control  applications;  modification  of  alarm  limits  and  routing;  and  the  production 
of  summaries  of  the  occurrence  of  such  alarms  and  events. 

BACnet  defines  two  different  mechanisms  for  generating  alarms  and  events.  One  is  called 
"intrinsic  reporting"  because  it  relies  on  the  use  of  properties  that  are  part  of  or  "intrinsic"  to  the 
object  that  is  being  monitored  for  alarms  or  events.  The  other  mechanism  is  called  "algorithmic 
change  reporting.”  Algorithmic  change  reporting  is  more  general  but  is  also  requires  the 
overhead  of  an  additional  object  called  the  Event  Enrollment  object.  The  intrinsic  reporting 
method  is  preferred  under  circumstances  where  it  meets  the  objectives  of  the  intended 
application. 

3.2.1  Alarm  and  Event  Management  • Specification  Issues  and  Recommendations 

Alarm  lists,  operator  notification  and  presentation  of  event  information 

The  nature  of  each  desired  alarm  condition  and  the  way  in  which  operators  are  notified 
about  alarms  and  events  should  be  clearly  described. 

• Specify  all  desired  alarms  on  a system-by-system  basis,  including  alarm  limits, 
interlocks  to  avoid  "nuisance”  alarms  (e.g.,  no  temperature  alarms  when  fan 
system  is  not  running  or  during  start-up  or  shut-down  transitions),  and  desired 
response  time  from  the  occurrence  of  an  event  until  a notification  is  provided. 

• Specify  how  alarms  are  to  be  categorized  and  distributed.  This  will  be  discussed 
more  frilly  below. 

• Specify  how  alarms  are  to  appear  at  the  operator  workstation. 

• Specify  that  intrinsic  reporting  shall  be  used  when  it  is  sufficient  to  meet  the 
functional  requirements. 


Alarm  acknowledgment 

It  may  be  important  to  know  which  operator  acknowledged  an  alarm  and  when. 


5 


• Specify  that  alarm  acknowledgment  capability  be  provided  and  that  a log  be 
maintained  that  records  when  an  alarm  notification  was  received,  when  it  was 
acknowledged,  and  by  whom. 

Alarm  summarization 

It  should  be  possible,  at  any  time,  to  determine  the  status  of  all  defined  alarms. 

• Specify  that  it  shall  be  possible  for  an  operator  to  receive,  at  any  time,  a 
summary  of  all  alarms  that  are  currently  in  effect  and  whether  or  not  they  have 
been  acknowledged. 

• Specify  that  is  shall  also  be  possible  to  receive  a summary  of  all  alarms 
regardless  of  acknowledgment  status;  for  which  a particular  recipient  is  enrolled 
for  notification;  based  on  current  event  state;  based  on  the  particular  BACnet 
event  algorithm  (e.g.,  change  of  value,  change  of  state,  out  of  range,  and  so  on); 
alarm  priority;  and  notification  class.  These  concepts  will  be  discussed  more 
fully  below. 

Alarm  parameter  adjustment 

It  should  be  possible  for  an  operator  to  modify  the  alarm  limits,  in  those  cases  where  an 
alarm  is  based  on  a value  exceeding  some  predefined  limit  value,  or  other  parameters 
used  in  computing  that  an  alarm  has  occurred. 

• Specify  that  operators  shall  be  provided  the  capability  to  dynamically  modify 
the  alarm  parameters  for  all  standard  BACnet  event  types. 

Alarm  routing  adjustment 

BACnet  provides  the  capability  to  direct  alarms  to  different  destinations  based  on  the 
type  and  priority  of  the  alarm,  the  day  of  week,  the  time  of  day,  and  so  on. 

• Specify  that  operators  shall  have  the  ability  to  change  alarm  routing  for  each 
alarm  including  the  destination  for  each  type  of  alarm  and  alarm  priority,  the 
day  of  week  and  time  of  day,  and  the  type  of  transition  involved  (TO- 
OFFNORMAL,  TO-NORMAL  and  so  on). 

3.3  Scheduling 

"Scheduling”  is  the  exchange  of  data  between  BACnet  devices  related  to  the  establishment  and 
maintenance  of  dates  and  times  at  which  specified  output  actions  are  to  be  taken.  Interoperability 
in  this  area  permits  the  use  of  date  and  time  schedules  for  starting  and  stopping  equipment  and 
changing  control  setpoints  as  well  as  other  analog  or  binary  parameters. 
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3.3.1  Scheduling  - Specification  Issues  and  Recommendations 

Schedule  list 

In  order  for  suppliers  to  size  their  systems  correctly  in  terms  of  their  scheduling 
capabilities,  a list  of  scheduled  activities  should  be  provided. 

• Specify  each  action  that  should  take  place  based  on  the  date  and  time  of  day. 
This  should  include  each  start/stop  operation  and  each  change  of  operating 
setpoints  and  parameters  based  on  operating  mode,  e.g.,  night  set-back,  vacation 
and  holiday  operation,  special  event  operation,  and  so  on. 

Display  of  start  and  stop  times  of  scheduled  devices 

BACnet  provides  the  capability  to  implement  control  actions  based  on  dates  and  times. 
These  actions  can  cause  devices  to  start  and  stop  or  setpoints  or  other  analog  parameters 
to  be  modified.  It  is  important  for  an  operator  to  be  able  to  ascertain  what  actions  are 
scheduled  for  any  given  date  and  time. 

• Specify  that  an  operator  shall  be  able  to  inspect  the  content  of  any  schedule  and 
determine  the  specific  control  actions  that  will  occur  at  any  time,  on  any  date. 
Additionally,  for  any  particular  device  or  system  parameter  that  is  the  subject  of 
a schedule  an  operator  shall  be  able  to  determine  the  schedule  of  actions  related 
to  that  device  or  parameter. 

Modification  of  schedules 

Although  BACnet  defines  the  operation  of  calendars  and  schedules,  it  does  not  require 
that  they  be  modifiable  in  all  cases  over  the  network.  If  this  is  needed,  it  should  be 
definitively  specified. 

• Specify  that  certain,  or  all,  calendar  entries  and  schedules  shall  be  modifiable 
from  an  operator  workstation. 


3.4  Trending 

"Trending"  is  the  accumulation  of  (time,  value)  pairs  at  specified  rates  for  a specified  duration. 
The  values  are  those  of  a specific  property  of  a specific  object.  "Trending"  is  distinguished  from 
the  real-time  plotting  of  data  (see  3.1.1)  in  that  the  data  are  usually  destined  for  long-term  storage 
and  the  sampling  intervals  are  usually  longer.  Interoperability  in  this  area  permits  the 
establishment  of  trending  parameters  and  the  subsequent  retrieval  and  storage  of  trend  data. 

3.4.1  Trending  - Specification  Issues  and  Recommendations 

Archival  storage  of  data 

It  should  be  possible  to  archive  data  values  from  any  networked  device  but  the  supplier 
needs  to  be  able  to  calculate  the  required  disk  storage. 
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• Specify  the  maximum  number  of  data  points  for  which  archival  storage  is  likely 
to  be  desired.  A distinction  should  be  made  between  points  with  true  historical 
value,  e.g.,  energy  use,  and  those  that  only  need  to  be  trended  for  a short  period 
of  time  such  as  points  used  to  verify  system  operation  following  a repair  or 
retrofit. 

• Specify  the  minimum  sampling  interval  required.  For  long-term  trending,  a rate 
of  5-6  samples  per  hour  will  often  suffice. 

• Specify  the  duration  of  time  for  which  the  archived  information  must  be 
available  for  on-line  retrieval.  One  to  two  years  will  often  be  adequate. 

• Specify  the  means  for  archiving  older  data.  A reliable  tape  system  or  writable 
CD  would  be  appropriate. 


Trend  list 

In  order  for  suppliers  to  size  their  systems  correctly  in  terms  of  their  trending  capabilities, 
a list  of  initially  required  trend  logs  should  be  provided. 

• Specify  the  initial  requirements  for  trending  in  terms  of  which  data  points  are  to 
be  trended,  the  sampling  rate,  the  duration  of  each  trend  log,  and  the  length  of 
time  it  is  desired  to  keep  the  resulting  logs  available  on-line.  Alternatively, 
specify  the  approximate  number  of  desired  trend  logs  along  with  other 
parameters. 

Display  and  archive  of  trend  data 

BACnet  provides  the  capability  for  field  devices  to  collect  data  and  then  notify  a 
workstation  or  storage  device  that  a trend  log  is  available  for  retrieval 

• Specify  that  an  operator  will  be  able  to  retrieve  and  display  trend  logs,  access 
the  underlying  numerical  data  in  spreadsheet  format,  and  output  the  data  to 
printers  or  other  files. 

Modification  of  trend  log  parameters 

Operators  with  sufficient  privilege  should  be  able  to  modify  the  trend  log  parameters  on- 
line from  any  BACnet  workstation. 

• Specify  that  the  data  points  to  be  logged,  the  sampling  rate,  and  duration  of 
trend  logs  shall  be  modifiable  by  an  authorized  operator  from  a system 
workstation. 
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3.5  Device  and  Network  Management 


"Device  and  network  management"  is  the  exchange  of  data  between  BACnet  devices  concerning 
the  operation  and  status  of  specific  devices.  Interoperability  in  this  area  permits  determining 
which  devices  are  present  on  a given  network  and  some  of  their  operational  capabilities, 
including  which  objects  they  maintain;  the  ability  to  start  up  and  shut  down  communication  from 
a particular  device;  the  ability  to  synchronize  the  time  in  those  devices  that  maintain  clocks;  the 
ability  to  reinitialize  the  operation  of  a device’s  computer;  the  ability  to  establish  connections  as 
needed;  and  the  ability  to  change  the  connection  configuration. 

3.5.1  Device  and  Network  Management  - Specification  Issues  and  Recommendations 

Display  of  information  about  device  status 

An  operator  should  be  able  to  query  the  status  of  any  device  on  the  internetwork. 

• Specify  that  an  operator  shall  be  able  to  display  at  any  time  the  operational 
status  of  any  device  on  the  BACnet  internetwork. 

Display  of  information  about  any  BACnet  object 

An  operator  should  be  able  to  display  information  about  any  BACnet  object  or  group  of 
BACnet  objects. 

• Specify  that  an  operator  shall  be  able  to  display  at  any  time  any  property  of  any 
BACnet  object. 

• Specify  that  an  operator  shall  also  be  able  to  display  property  values  of  objects 
grouped  by  object  type,  object  location,  building  system,  and  so  on. 

Ability  to  silence  a device  on  the  network  that  is  transmitting  erroneous  data 

If  a sensor  malfunction  should  occur,  an  operator  should  be  able  to  quiesce  the  offending 
device  until  repairs  can  be  effected. 

• Specify  that  an  operator  shall  be  able  to  direct  a field  device  to  stop  transmitting 
event  or  alarm  notifications  until  a subsequent  command  to  resume 
transmissions  is  received. 

Ability  to  synchronize  the  time  in  devices  across  the  BACnet  inter-network 

It  should  be  possible  for  an  operator  to  issue  time  synchronization  commands  to  one  or 
more  devices  as  needed.  This  capability  is  independent  of  the  existence  of  a "time 
master"  on  the  network  that  carries  out  time  synchronizations  automatically. 

• Specify  that  an  operator  shall  be  able  to  set  the  time  and  date  in  any  device  on 
the  network  that  supports  time-of-day  functionality.  This  capability  should  be 
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provided  for  both  individual  devices  or  groups  of  devices,  including  all  devices 
simultaneously. 

Ability  to  cause  a remote  device  to  reinitialize  itself 

BACnet  provides  the  capability  to  issue  a command  that  will  cause  a remote  device  to 
"reinitialize"  itself.  This  usually  amounts  to  restarting  or  rebooting  the  computer  itself 
and  starting  any  control  activities  "from  scratch." 

• Specify  that  an  operator  shall  have  the  ability  to  issue  reinitialization  commands 
to  any  device  that  supports  remote  reinitialization. 

Ability  to  backup  and  restore  the  configuration  of  other  devices 

BACnet  provides  the  ability  for  devices  to  be  backed  up  and  restored  over  the  network. 
Although  not  all  devices  support  this  capability  (e.g.,  because  the  operating  software  is 
ROM-based),  it  is  still  important  to  have  this  ability  if  available. 

• Specify  that  an  operator  shall  have  the  ability  to  backup  and  restore  all  BACnet 
devices  on  the  network  that  support  this  capability. 

Ability  to  command  half-routers  to  establish  and  terminate  connections 

BACnet  "half-routers"  are  used  to  provide  connectivity  to  remote  sites,  usually  on  a 
temporary  basis,  using  dial-up  telephone  technology. 

• Specify  that  an  operator  shall  have  the  ability  to  issue  a command  for  the 
establishment  or  termination  of  a connection  to  a remote  BACnet  network. 

Ability  to  query  and  change  the  configuration  of  half-routers  and  routers 

Operators  should  have  the  ability  to  change  the  database  entries  that  half-routers  and 
routers  use  to  establish  communications  with  remote  BACnet  networks. 

• Specify  that  an  operator  shall  have  the  ability  to  display  and  modify  the  routing 
table  entries  in  all  provided  BACnet  half-routers  and  routers. 

4 Use  of  BACnet  Objects 

BACnet  objects  form  the  basis  for  representing  the  functionality  of  building  automation  and 
control  equipment  in  a standard,  network- visible  way.  The  original  BACnet  standard  defined  18 
object  types  and  3 more  are  in  the  final  approval  stage.  While  the  use  of  the  Interoperability 
Areas  described  above  in  conjunction  with  the  device  profiles  of  Annex  A should  result  in 
devices  being  provided  with  a known  set  of  BACnet  capabilities,  the  number  and  type  of 
BACnet  objects  that  will  be  provided  depends  on  the  specificity  of  the  desired  control  sequences 
of  operation  and  other  functional  requirements  of  a particular  installation,  such  as  the  number  of 
alarms,  trending  logs,  schedules,  metering  points,  and  so  on.  In  this  section  a number  of 
specification  issues  will  be  presented  that  are  specific  to  BACnet  objects. 


10 


4.1  Naming  Conventions 


BACnet  objects  are  uniquely  identified  within  a particular  BACnet  device  by  a 32-bit  numeric 
"object  identifier."  While  this  expedites  access  over  the  network  and  allows  implementers  to 
know,  in  advance,  how  much  storage  to  allocate  for  these  identifiers,  their  use  by  human 
operators  would  be  highly  impractical  Therefore,  BACnet  also  allows  each  object  to  be 
referenced  by  an  "object  name."  The  standard,  however,  only  specifies  a minimum  length  of  one 
printable  character  for  the  object  name  and  does  not  even  require  that  it  be  writable,  Le., 
modifiable,  once  a device  is  commissioned.  This  was  done  to  accommodate  very  simple  devices, 
such  as  might  be  employed  as  unitary  or  application  specific  controllers. 

Both  object  identifiers  and  object  names  are  required  to  be  unique  within  the  device  that  contains 
them.  There  is  an  additional  constraint  on  the  Device  object  that  its  name  and  object  identifier  be 
unique  within  the  entire  BACnet  internetwork  including  any  temporary  dial-up  connections. 
Except  for  the  Device  object,  manufacturers  can  freely  configure  object  identifiers  with  no 
adverse  impact  on  interoperability  or  the  expandability  of  the  system.  The  special  case  of  Device 
object  identifiers  is  discussed  in  6.5.  Object  names  should  be  assigned  according  to  a convention 
established  by  the  facility  manager  and  not  left  for  the  manufacturer  to  arbitrarily  decide. 

The  use  of  object  names  typically  comes  up  in  two  very  different  contexts.  The  first  is  in  the 
programming  of  BACnet  devices  for  a particular  purpose  where  an  object  is  referred  to  in  the 
program.  The  second  is  in  referring  to  the  object  from  a workstation  where  an  operator  may  want 
to  view  properties  of  a particular  object  or  insert  a property  in  a graphic  or  in  a tabular  report.  In 
the  latter  case,  the  workstation  will  generally  retain  a mapping  of  the  workstation  name  to  the 
object  identifier  (or  object  name)  used  in  the  remote  device. 

The  basic  principle  to  follow  in  setting  up  site-wide  object  (and  device)  naming  conventions  is 
that  the  names  should  be  as  meaningful  as  possible  given  the  name  length  available.  Thus, 
"AHU1.STEMP"  would  be  preferable  to  a more  cryptic  name  like  "A1ZXC5".  An  often  used 
convention  is  to  construct  a name  from  a set  of  components,  each  of  which  relates  to  the  building 
system  installation.  In  this  scheme  the  compound  name  is  constructed  from  the  building  or 
facility  in  which  the  system  is  located,  the  name  of  the  building  system  itself,  and,  finally,  the 
name  of  the  desired  point.  An  example  of  this  FACILITY.  SYSTEM.POENT  (FSP)  naming 
method  is  ”BLDG226.AHU1.MA_TEMP".  The  facility  is  Building  226,  the  system  is  Air 
Handler  Unit  1,  and  the  point  is  the  mixed  air  temperature.  The  convention  may  be  easily 
extended  to  accommodate  areas  within  the  facility,  and  subsystems  within  a system.  For 
example,  "BLDG226.BASEMENT_MER.AHU  1 .CW.STEMP"  would  refer  to  the  supply 
temperature  of  the  chilled  water  subsystem  of  the  air  handler  located  in  the  basement  mechanical 
equipment  room. 

• Specify  a set  of  abbreviations  for  common  building  systems,  subsystems,  and  points 
that  are  to  be  used  by  all  vendors. 

• Specify  that  object  name  properties,  in  those  devices  where  the  object  name  is 
configurable,  shall  be  at  least  50  characters  long  and  shall  to  the  extent  possible  make 
use  of  a system  and  point  nomenclature  using  the  abbreviations  specified  above. 

• Specify  that  BACnet  object  names  used  in  workstations  may  be  up  to  50  characters 
long  and  shall  consist  of  a string  made  up  of  components  indicating,  as  appropriate,  the 
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location,  system,  subsystem,  and  point  of  the  object.  These  object  names  shall  be  used 
in  workstation  applications  such  as  graphics,  reports,  and  alarms  wherever  an  object 
name  is  appropriate  in  lieu  of  the  object  name  property  in  the  remote  device.  Moreover, 
an  operator  may  display  at  any  time  the  mapping  between  the  object  name  used  on  the 
workstation  and  the  object  name  property  used  in  the  remote  BACnet  device. 

4.2  Commissioning  / Diagnostic  Mode 

A powerful  feature  of  the  BACnet  object  model  is  the  ability  to  verify  controller  performance  by 
manipulating  properties  of  certain  objects  and  observing  the  resulting  device  operation.  For 
example,  the  Present. Value  property  of  an  Analog  Value  object  could  be  set  to  a value  above  the 
High.Limit  and  the  execution  of  a programmed  response  to  this  condition  could  then  be  verified. 
This  capability  is  of  particular  value  during  commissioning  or  for  diagnosing  problems 
subsequent  to  installation  and  acceptance. 

In  order  to  be  able  to  decouple  the  Present. Value  of  an  object  from  its  underlying  process  and 
force  it  to  take  on  a different  value,  the  object  must  first  be  taken  "out  of  service"  by  causing  its 
Out_Of_Service  property  to  be  TRUE.  The  Out_Of_Service  property  is  provided  for  the  Loop, 
Program  and  all  of  the  Analog,  Binary,  and  Multi-state  object  types.  In  order  to  accommodate  the 
requirements  of  very  simple  devices,  however,  BACnet  does  not  require  that  the  Out_Of_Service 
property  be  writable.  In  such  devices  Out_Of_Service  may  possibly  be  accessed  and  altered  by 
non-BACnet  means  such  as  proprietary  configuration  devices  or  protocols.  In  order  to  be  able  to 
conduct  commissioning  and  diagnostics  using  the  BACnet  network,  it  should  be  requested  that 
the  Out_Of_Service  property  be  writable. 

• Specify  that  the  Out_Of_Service  property  shall  be  adjustable  (writable)  using  BACnet 
services  for  all  Analog,  Binary,  Multi-state,  Loop  and  Program  objects. 

4.3  Using  Object  Descriptions 

All  BACnet  object  types  have  an  optional  character  string  Description  property  whose  length  and 
content  are  not  defined  or  limited.  The  idea  was  to  provide  a mechanism  to  allow  an  operator  or 
technician  to  obtain  useful  information  about  the  purpose  or  application  of  a particular  object  in 
any  BACnet  device.  The  Description  property  is  optional  because  text  takes  up  a relatively  large 
amount  of  memory  and  may  exceed  the  resources  of  simple  devices.  Also,  descriptive  object 
information  may  be  stored  in  a database  external  to  the  device  in  which  the  object  resides,  e.g.,  in 
a workstation,  thus  conserving  resources  in  a device  with  limited  storage. 

Nonetheless,  the  availability  of  a Description  property  in  certain  objects  is  highly  desirable.  This 
is  particularly  true  for  the  Device  object.  Its  description  can  convey  its  location,  purpose,  or  other 
significant  data. 

• Specify  that  each  Device  object  shall  have  a Description  property  and  that  the  length 
available  for  the  Description  properties  of  other  implemented  object  types  shall  be 
provided  in  the  "Property  Range  Restrictions"  portion  of  the  device's  PICS. 
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4.4  Issues  Related  to  Specific  BACnet  Object  Types 

The  specification  should  provide  direction  to  suppliers  for  the  values  to  be  assigned  to  certain 
properties  of  BACnet  objects  that  need  to  be  coordinated  and  made  consistent  in  the  case  where 
there  may  be  multiple  suppliers  on  a job.  In  BACnet,  the  values  of  these  properties  are  referred 
to  as  "local  matters,"  a term  meaning  that  the  value  depends  on  the  local  circumstances. 

4.4.1  Analog  Input,  Output,  and  Value 

The  analog  object  types  have  the  ability  to  announce  changes  of  value  using  the  COV 
reporting  method. 

• Specify  that  all  analog  objects  (Input,  Output,  and  Value)  shall  have  the 
capability  of  using  the  Change  of  Value  reporting  mechanism  and  that  the 
COV.Increment  property  shall  be  writable  using  BACnet  services. 


4.4.2  Binary  Input 

Binary  inputs  have  two  properties,  Inactive_Text  and  Active„Text,  whose  values  should 
be  specified. 

• Specify,  for  each  Binary  Input  object,  the  text  to  be  used  for  the  Inactive_Text 
and  Active_Text  properties.  For  example,  "On",  "Off";  "Running",  "Stopped", 
"Open",  "Closed",  and  so  on. 

4.4.3  Binary  Output 

In  addition  to  Inactive_Text  and  Active_Text,  Binary  Output  objects  may  need  to  have 
values  specified  for  the  Feedback_Value,  Minimum_On_T ime,  and  Minimum__Off_T ime 
properties. 

Binary  Output  objects  have  optional  properties  that  are  used  to  keep  track  of  how  many 
times  the  state  has  changed  and  to  accumulate  the  total  run  time.  If  either  of  these 
features  is  appropriate  for  the  application,  support  for  these  properties  must  be  specified. 

• Specify,  for  each  Binary  Input  object,  the  text  to  be  used  for  the  Inactive_Text 
and  Active_Text  properties.  In  addition,  if  appropriate  for  the  application,  also 
specify  appropriate  values  for  the  Feedback. Value,  Minimum_On_Time,  and 
Minimum_Off_T ime  properties. 

• Specify  support  for  the  Change_Of.State.Time,  Change_Of_State_Count,  and 
Time_Of_State_Count_Reset  if  counting  state  changes  is  appropriate  for  the 
application.  Also  specify  that  Change_Of_State_Count  be  writable  so  that  the 
count  can  be  reset. 

• Specify  support  for  the  Elapsed_Active_Time  and 
Time_Of_Active_Time_Reset  properties  if  accumulating  run  time  is  appropriate 
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for  the  application.  Also  specify  that  Elapsed_Active_Time  be  writable  so  that 
the  run  time  can  be  reset. 

4.4.4  Binary  Value 

In  addition  to  Inactive_Text  and  Active_Text,  Binary  Value  objects  may  need  to  have 
values  specified  for  the  Minimum_On_T ime,  and  Minimum_Off_Time  properties. 

Binary  Value  objects  have  optional  properties  that  are  used  to  keep  track  of  how  many 
times  the  state  has  changed  and  to  accumulate  the  total  run  time.  If  either  of  these 
features  is  appropriate  for  the  application  support  for  these  properties  must  be  specified. 

• Specify,  for  each  Binary  Value  object,  the  text  to  be  used  for  the  Inactive_Text 
and  Active_Text  properties.  In  addition,  if  appropriate  for  the  application,  also 
specify  appropriate  values  for  the  Minimum_On_Time,  and 
Minimum„Off_T ime  properties. 

• Specify  support  for  the  Change_Of_State_Time,  Change_Of_State_Count,  and 
Time_Of_State_Count_Reset  if  counting  state  changes  is  appropriate  for  the 
application.  Also  specify  that  Change_Of_State_Count  be  writable  so  that  the 
count  can  be  reset. 

• Specify  support  for  the  Elapsed_Active_Time  and 
Time_Of_Active_Time_Reset  properties  if  accumulating  run  time  is  appropriate 
for  the  application.  Also  specify  that  Elapsed_Active_Time  be  writable  so  that 
the  run  time  can  be  reset. 

4.4.5  Calendar 

Calendar  objects  store  lists  of  dates,  date  ranges,  or  month/week/day  combinations  like 
the  "first  Tuesday  of  every  month."  The  most  typical  use  of  a Calendar  object  would  be 
to  store  a list  of  holidays,  vacation  periods,  or  special  events  that  would  be  referenced  by 
a Schedule  object.  BACnet  does  not  specify  how  many  Calendar  objects  should  be 
provided,  how  many  entries  each  Calendar  must  allow,  or  even  that  the  entries  be 
modifiable  over  the  network. 

• Specify  that  devices  that  provide  scheduling  capability  shall  also  provide  at  least 
one  Calendar  object  with  a capacity  of  at  least  10  entries.  It  shall  be  possible  to 
view  the  Calendar  object  and  make  modifications  from  any  BACnet  workstation 
on  the  network. 

• Specify,  if  the  Calendar’s  Date_List  property  is  writable  using  BACnet  services, 
that  all  calendar  entry  datatypes  must  be  supported.  These  are  individual  dates, 
date  ranges,  and  specific  weeks  and  days  within  a month. 
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4.4.6  Loop 


Loop  objects  provide  a network  visible  representation  of  control  loops  including 
proportional-integral-derivative  (PID)  control  loops.  If  it  is  anticipated  that  building 
engineers  will  want  to  tune  such  control  loops  from  a BACnet  workstation  (as  opposed  to 
using  proprietary  tuning  methods),  Le.,  make  adjustment  to  the  various  gain,  bias,  and 
sampling  parameters,  then  the  use  of  Loop  objects  should  be  required. 

• Specify  that  the  desired  PID  control  loops  shall  be  represented  by  Loop  objects 
and  that  the  tuning  constant  properties  shall  be  writable.  These  include  the 
Update_Interval,  Setpoint,  ProportionaLConstant,  Integral_Constant, 
Derivative_Constant,  and  Bias.  Specify  writability  of  other  Loop  properties  as 
appropriate  to  the  application. 

• Specify  that  all  Loop  objects  shall  have  the  capability  of  using  the  Change  of 
Value  reporting  mechanism  and  that  the  COV_Increment  property  shall  be 
writable  using  BACnet  services. 

4.4.7  Multi-state  Input,  Output,  and  Value 

The  Multi-state  object  types  have  State_Text  properties  that  describe  each  of  the  possible 
states  that  the  Present_Value  of  the  object  may  take  on.  In  addition.  Multi-state  Output 
objects  may  have  a Feedback_Value. 

• Specify,  for  each  Multi-state  Input,  Output,  and  Value  object,  the  text  to  be  used 
for  each  state  that  the  object  can  represent.  In  addition,  if  appropriate  for  the 
application,  also  specify  how  the  Feedback^ Value  is  to  be  determined. 

• Specify  that  all  Multi-state  Input,  Output,  and  Value  objects  shall  have  the 
capability  of  using  the  Change  of  Value  reporting  mechanism  and  that  the 
COV_Increment  property  shall  be  writable  using  BACnet  services. 

4.4.8  Schedule 

Schedule  objects  provide  a way  to  alter  binary  or  analog  values  based  upon  date  and  time. 
These  values  will  typically  be  associated  with  physical  outputs  or  with  operational 
parameters  such  as  setpoints.  A single  schedule  may  be  applied  to  multiple  data  points, 
each  of  which  are  subject  to  the  same  value  being  applied  at  the  same  time,  e.g.,  multiple 
fan  systems,  all  of  which  are  turned  on  at  7 A.M.  and  off  at  6 P.M.  during  the  work  week. 
However,  BACnet  does  not  specify  how  many  Schedule  objects  should  be  provided,  or 
that  any  of  their  properties  must  be  modifiable  over  the  network. 

• Specify  each  building  system  that  is  to  be  subjected  to  date  and  time  scheduling 
and  specify  that  it  shall  be  possible  to  modify  schedule  entries  from  a BACnet 
workstation. 
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4.5  Dynamic  Object  Creation 


BACnet  provides  the  ability  to  create  new  objects  dynamically,  Le.,  after  a device  has  been 
configured  initially.  While,  in  theory,  new  instances  of  any  object  type  could  be  created,  the 
primary  use  of  this  capability  is  the  creation  of  Averaging,  Calendar,  Event  Enrollment,  Group, 
Notification  Class,  Schedule,  and  Trend  Log  objects. 

• Specify,  if  required  by  the  application,  that  it  shall  be  possible  to  dynamically  create 
instances  of  the  Averaging,  Calendar,  Event  Enrollment,  Group,  Notification  Class, 
Schedule,  and  Trend  Log  objects. 

5 Use  of  BACnet  Services 

The  following  sections  discuss  specific  issues  related  to  the  use  of  BACnet  "services,"  the  client- 
server  messages  that  are  exchanged  between  BACnet  devices. 

5.1  Interoperable  Commands 

One  of  the  most  significant  aspects  of  BACnet  is  the  implementation  of  a "command  priority" 
scheme.  This  makes  possible  the  "prioritization"  of  commands  from  various  control  processes, 
e.g.,  start-stop  commands  or  setpoint  changes,  so  that  it  is  predictable  which  command  will  be 
carried  out.  This  is  implemented  by  assigning  "command  priority  levels"  to  the  various 
processes.  BACnet  prescribes  a set  of  standard  priority  levels  as  shown  in  Table  1: 


Table  1.  Standard  Command  Priorities 


Priority 

Level 

Application 

Priority 

Level 

Application 

1 

Manual-Life  Safety 

9 

Available 

2 

Automatic-Life  Safety 

10 

Available 

3 

Available 

11 

Available 

4 

Available 

12 

Available 

5 

Critical  Equipment  Control 

13 

Available 

6 

Minimum  On/Off 

14 

Available 

7 

Available 

15 

Available 

8 

Manual  Operator 

16 

Available 

Note  that  priority  levels  3,  4,  7,  and  1-16  are  available  for  assignment.  Thus  the  task  for  the 
designer  becomes  1)  deciding  what  processes  need  to  be  included  in  the  prioritization  scheme 
and  2)  what  relative  importance,  Le.,  command  priority  level  each  should  be  assigned  to. 
Examples  of  processes  that  should  be  considered  for  prioritization  are:  peak  demand  limiting. 
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night  set-back,  night  cooling,  and  optimum  start-stop.  Interoperable  command  priorities  must  be 
applied  uniformly  throughout  the  entire  internetwork. 

• Specify  the  processes  that  are  to  be  prioritized  and  the  command  priority  levels  assigned 
to  each  if  they  do  not  fall  into  the  pre-assigned  levels  shown  in  Table  1.  For  each  point 
subject  to  the  command  priority  scheme,  specify  a default  status,  position,  or  value  for 
the  point  to  take  on  in  the  absence  of  a prioritized  command. 

5.2  Alarm  Considerations 

This  section  describes  design  considerations  relating  to  alarm  management  in  BACnet  systems. 

5.2.1  Assigning  Alarm  Priorities 

BACnet  provides  the  ability  to  assign  a numeric  priority  to  each  event  transition  for  which 
notification  is  desired.  The  transitions  are  TO-OFFNORMAL,  TO-FAULT,  and  TO-NORMAL. 
The  meaning  of  each  transition  depends  on  the  algorithm  used  to  process  the  alarm  inputs.  The 
most  common  algorithms  have  been  standardized  and  are  precisely  defined  in  BACnet.  They  are 
Change  of  Bitstring,  Change  of  State,  Change  of  Value,  Command  Failure,  Floating  Limit,  and 
Out  of  Range  alarms. 

Priority  values  range  from  0 to  255  with  0 being  the  highest  priority  and  255  the  lowest.  Typical 
installations  will  use  only  a small  number  of  discrete  values  such  as  "255,  128,  0”  for  "low, 
medium,  high”  but  the  values  to  be  used  need  to  be  conveyed  to  the  installers.  Events  of  type 
Alarm  are  generated  in  BACnet  by  objects  that  support  "intrinsic  reporting"  or  by  Event 
Enrollment  objects.  Object  types  that  support  intrinsic  reporting  are  the  Analog  Input,  Output, 
and  Value;  Binary  Input,  Output,  and  Value;  Multi-state  Input,  Output,  and  Value;  and  Loop. 
Intrinsic  reporting  is  tightly  prescribed  in  that  it  pertains  only  to  an  object’s  Present_Value  or 
Status_Flags  properties.  Event  Enrollment  objects  can  apply  the  standard  algorithm  types  to  any 
property  of  any  object. 

In  general,  alarm  distribution  is  managed  by  the  use  of  "notification  classes"  which  are  described 
in  next  section.  One  of  the  parameters  conveyed  in  the  alarm  notification  is  the  priority  value 
which  is  a property  of  the  associated  Notification  Class  object  or  the  Event  Enrollment  object. 
The  use  to  which  the  priority  is  put  is  not  dictated  by  BACnet. 

The  task  of  the  designer  is  to  assign  priority  values  to  the  alarms  that  are  to  be  implemented  and 
to  specify  the  actions  to  be  taken  by  recipients  upon  receipt.  These  could  include  directing  the 
notification  to  a printer;  sounding  an  audible  or  visual  signal;  generating  a report  with  alarms  of 
the  same  priority  collected  together;  and  so  on. 

•Specify  the  priority  values  to  be  assigned  for  each  alarm  in  the  system.  For  each 
priority  value,  or  range  of  values,  specify  the  actions  to  be  taken  upon  receipt. 

5.2.2  Setting  up  Notification  Classes 

As  mentioned  in  the  preceding  section,  BACnet  provides  the  ability  to  direct  alarms  to  different 
destinations  based  on  the  type  of  the  alarm  transition,  the  day  of  week,  and  the  time  of  day.  The 
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mechanism  for  achieving  this  is  to  create  and  configure  Notification  Class  objects,  each  of  which 
is  referenced  by  other  processes  as  a simple  integer  known  as  the  "notification  class." 

In  the  most  elementary  situation,  there  would  be  a single  notification  class,  perhaps  statically 
configured  as  a default,  that  would  be  valid  24  hours  a day  and  would  direct  all  messages  to  a 
single  recipient.  In  the  more  general  case,  there  might  be  multiple  recipients  who  should  only 
receive  specific  types  of  alarms  and,  perhaps,  only  at  certain  hours  of  the  day.  A building 
manager,  for  instance,  might  receive  all  alarms  at  all  times,  but  only  critical  alarms  would  be  sent 
via  a pager  or  to  the  night  shift  operator  between  midnight  and  8 A.M. 

• Specify  how  alarms  should  be  distributed  by  specifying  the  recipients  of  each  type  and 
priority  of  alarm.  If  desired,  specify  the  valid  days  of  the  week  and  times  of  the  day  for 
each. 

5.23  Event  Notification  Message  Texts 

The  occurrence  of  alarms  and  events  in  BACnet  is  signaled  by  the  transmission  of  "Event 
Notification"  messages.  These  messages  convey  most  of  the  information  that  is  important  about 
the  occurrence  including  the  "what,  when,  and  where."  There  is  also  an  optional  parameter  called 
Message  Text'.  While  many  current  systems  use  workstation  software  to  translate  an  alarm 
identifier  into  text  meaningful  to  an  operator,  the  text  message  may  also  be  composed  by 
software  resident  in  a field  device  and  sent  along  with  the  other  alarm  data.  Either  way,  it  is 
useful  to  specify  the  desired  content  and  format  of  the  alarm  messages  that  will  be  seen  by  an 
operator.  Apart  from  the  alarm  details,  the  messages  can  also  be  used  to  indicate  any  necessary 
actions  to  be  taken.  The  messages  might  contain,  for  example,  the  name  of  a particular  mechanic, 
service  contractor,  or  phone  number  to  be  called,  or  indicate  that  certain  other  data  points  should 
be  inspected  to  verify  the  validity  of  the  alarm  condition. 

• Specify  the  content  and  format  of  the  alarm  messages  that  will  be  delivered  to 
operators. 

53  Assigning  Levels  of  Authority  to  Certain  Operators 

Tracking  the  acknowledgment  of  alarms  is  one  important  aspect  of  facility  management.  BACnet 
devices  can  be  configured  to  accept  alarm  acknowledgments  only  from  specific  personnel  The 
broader  issue  is  the  assignment,  if  deemed  appropriate,  of  differing  levels  of  operational 
authority  to  different  personnel  While  this  is  mainly  an  administrative  issue  relating  to  the 
configuration  of  workstation  software,  several  BACnet  services  have  optional  password 
protection.  They  are  the  remote  device  management  services,  DeviceCommunicationControl  and 
ReinitializeDevice.  The  first  allows  an  operator  to  "quiesce"  a device  that  is  generating  specious 
messages  due,  for  example,  to  a defective  sensor,  and  the  second  forces  a remote  device  to  go 
through  a restart  process.  In  each  case,  the  passwords  are  character  strings  of  up  to  twenty 
characters  that  are  programmed  into  the  remote  devices. 

• Specify,  if  desired,  the  number  of  authorization  levels  and  the  operator  accounts  to  be 
assigned  to  each.  If  password  protection  for  remote  device  management  services  is 
needed,  specify  the  passwords  to  be  configured.  Alternatively,  specify  that  there  shall 
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be  a method  provided  for  dynamically  assigning  passwords  for  remote  device 
management  functions  after  installation. 

5.4  Change  of  Value  Processing 

A powerful  BACnet  capability  is  that  of  "change  of  value"  (COV)  reporting.  In  essence,  certain 
standard  object  types  can  be  configured  to  generate  a notification  when  their  present  values 
change  by  a prescribed  amount  or  their  status  flags  (the  bits  that  indicate  an  object’s  in-alarm, 
fault,  overridden,  and  out-of-service  status)  change  at  all  The  object  types  that  possess  this 
optional  capability  are  the  Analog,  Binary,  and  Multi-state  Input,  Output,  and  Value,  and  the 
Loop.  This  type  of  COV  notification  can  be  useful  for  efficiently  updating  real-time  graphic 
displays  and,  in  terms  of  limiting  unnecessary  network  traffic,  is  preferable  to  continuously 
reading  the  value  of  a point  to  detect  a change  of  value. 

5.4.1  Subscribed  COV  Notifications 

In  order  to  receive  COV  notifications,  a subscription  request  must  be  sent  to  the  device  which 
contains  the  objects  in  question. 

• Specify  workstation  software  shall  have  the  capability  of  subscribing  to  COV 
notifications  for  all  object  types  that  support  it. 

5.4.2  Unsubscribed  COV  Notifications 

A new  feature  of  BACnet  that  is  currently  under  public  review  is  the  use  of  the 
UneonfirmedCOVNotification  service  as  a means  of  distributing  COV  notifications  for  changes 
that  have  not  been  subscribed  to.  This  mechanism  is  intended  to  be  used  for  distributing  shared, 
globally  significant,  values,  e.g.,  a common  outside  air  temperature  or  a binary  value  indicating 
whether  a building  is  "occupied"  or  not 

• Specify  that  changes  of  value  of  globally  shared  data  shall  be  distributed  by  means  of 
UnconfirmedCOVNotifications. 

5.5  Time  Synchronization 

It  may  be  desirable  to  provide  a standardized  time  reference  for  a single  building  system  or  group 
of  systems.  In  BACnet,  Time  synchronization  is  achieved  by  defining  a computer  to  serve  as  a 
"Time  Master."  Depending  on  the  scope  of  a particular  project,  Le.,  whether  it  is  localized  or 
spans  time  zones,  it  may  be  desirable  to  use  "Coordinated  Universal  Time"  (UTC)  as  the 
reference  rather  than  local  time. 

• Specify  that  a time  master  shall  be  provided  and  the  format  of  the  time  synchronization 
messages,  either  local  time  or  UTC. 


6 Specifying  System/Network  Architectures 


BACnet  provides  considerable  flexibility  in  the  selection  of  network  types  and  interconnections 
between  them.  This  section  discusses  the  issues  involved  with  deciding  which  network  types  to 
use  and  how  to  interconnect  them. 


6.1  System  Architectures 


The  term  "system  architecture"  refers  to  the  arrangement  of  networks  that  make  up  an 
"internetwork."  See  Figure  6-1.  Note  that  in  BACnet,  each  network  in  an  internetwork,  is 
identified  by  a unique  "network  number."  The  assignment  of  network  numbers  is  further 
discussed  in  6.4. 
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Figure  6-1.  An  Example  of  a BACnet  Internetwork 
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The  simplest  configuration  is  a network  comprised  of  a single  physical  segment  with  all  devices 
directly  attached  to  it.  The  issue  is  then  which  local  area  network  (LAN)  type  to  select.  This  is 
discussed  in  6.2.  Since  all  LANs  have  some  distance  limitation,  multiple  physical  segments  may 
have  to  be  joined  by  repeaters  or  bridges  which  selectively  forward  traffic  based  on  knowledge 
of  where  specific  devices  are  located.  If  several  networks  need  to  be  interconnected,  BACnet 
routers  are  available  that  can  join  networks  using  the  same,  or  different,  LAN  technology.  A key 
point  is  that  slower  networks  should  not  be  used  to  interconnect  faster  ones.  Also,  BACnet 
should  be  used  throughout  unless  there  are  existing  "legacy”  networks  to  which  a connection 
must  be  made.  Such  connections  require  the  use  of  translators  or  "gateways"  which  almost 
inevitably  affect  performance,  throughput,  and  functionality  in  a negative  way.  See  6.8. 

• Specify  that  BACnet  shall  be  used  throughout  the  building  automation  and  control 
internetwork  at  all  levels. 

• Specify  that  the  internetwork  shall  be  configured  such  that,  if  three  or  more  networks 
are  involved  with  different  performance  characteristics,  the  faster  networks  shall  be 
used  to  interconnect  the  slower  ones. 

6.2  Local  Amt  Network  Selection 

BACnet  provides  a great  deal  of  flexibility  in  configuring  different  LAN  technologies  for 
optimal  price  vs.  performance  tradeoffs  to  meet  the  particular  needs  of  a facility.  The  ability  to 
use  multiple  LAN  technologies  also  permits  BACnet  systems  to  accommodate  new  network 
technologies  in  the  future  while  maintaining  backward  compatibility  with  installed  system 
components. 

BACnet  currently  supports  four  different  LAN  technologies,  each  one  having  particular  pros  and 
cons.  Figure  6-2  illustrates  the  range  of  options  presently  in  BACnet.  Each  technology  is  shown 
as  a bubble.  This  reflects  the  fact  that  even  within  one  LAN  technology  there  are  choices  of 
media,  topology,  and  in  some  cases  speed  that  effect  the  price  and  performance. 

Sections  6.2.1  - 6.2.5  explain  in  more  detail  the  important  features  that  should  be  considered 
when  deciding  on  the  appropriate  LAN  technologies  to  use. 
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Figure  6-2.  Cost  vs.  Performance  for  BACnet  LAN  Options 

6.2.1  ISO  8802-3,  Ethernet 

ISO  8802-3  is  commonly  known  by  the  name  "Ethernet."  This  is  probably  the  most  widely  used 
LAN  technology  in  the  world  today,  primarily  because  of  its  ubiquitous  presence  in  office  and 
business  networks.  It  is  the  fastest  LAN  technology  used  in  BACnet.  Most  building  control 
companies  offer  Ethernet  as  an  option  for  connecting  high-end  controllers  with  each  other  and 
with  workstations.  The  key  features  of  Ethernet  are  summarized  in  Table  6-1. 


Table  6-1.  Features  of  ISQ-8802-3,  Ethernet 


Pros 

Cons 

• international  standard 

• already  used  in  most  buildings 

• variety  of  media  (UTP,  coax,  fiber  optic) 

• very  fast  (10  Mbps  or  100  Mbps) 

• easy  to  interface  with  PCs 

• the  protocol  is  implemented  in  a chip 

• no  special  development  tools 

• relatively  high  cost 

• distance  limitations 

• non-deterministic 

Each  of  the  media  options  has  different  cost,  different  length  limitations,  and  different 
susceptibility  to  electrical  interference.  Coaxial  cables  are  the  lowest  cost  and  they  are  restricted 
to  a bus  topology.  Unshielded  twisted  pair  (UTP)  wiring  is  done  in  a star  configuration  and 
requires  the  use  of  hubs.  This  is  a very  robust  architecture  and  offers  maximum  flexibility  with 
respect  to  the  physical  location  of  the  connected  devices  but  it  costs  more  because  of  the  hubs. 
Fiber  optic  cables  have  the  most  immunity  to  electrical  interference,  can  span  longer  distances, 
and  are  the  most  expensive  option.  It  is  possible  to  mix  the  various  media  in  a single  system. 
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The  10  Mbps  Ethernet  technology  is  sufficient  to  meet  the  needs  of  most  building  control 
applications.  Under  some  circumstances  it  may  be  desirable  to  use  an  existing  100  Mbps  LAN 
for  a portion  of  the  control  system,  a workstation  for  example.  It  is  possible  to  connect  10  Mbps 
segments  to  100  Mbps  segments  by  using  special  hubs. 

Although  Ethernet  is  the  fastest  LAN  option  in  BACnet  it  is  non-deterministic.  This  means  that  it 
is  not  possible  to  guarantee  that  a device  will  be  able  to  transmit  a message  within  a specific 
amount  of  time.  This  is  a consequence  of  the  fact  that  Ethernet  uses  a contention-based  scheme 
to  regulate  access  to  the  transmission  medium.  A device  can  transmit  a message  anytime  the 
network  is  quiet.  If  two  devices  decide  to  transmit  at  the  same  time  a collision  occurs.  Collisions 
only  become  a problem  in  networks  with  high  traffic  volumes.  If  the  network  is  properly 
designed  and  maintained  this  difficulty  can  be  avoided.  In  this  context,  "proper  design"  may 
involve,  among  other  things,  distributing  nodes  likely  to  generate  high  traffic  volume  onto  more 
than  one  Ethernet  segment  and  using  bridges  between  segments  that  isolate  "local"  traffic  so  that 
it  is  not  propagated  to  all  nodes. 

Specifying  Ethernet  LANs 

Because  of  its  cost,  an  Ethernet  LAN  is  generally  used  as  a backbone  network  connecting 
workstations  and  supervisory  controllers  together.  The  various  options  available  make  it 
necessary  to  indicate  which  ones  are  acceptable. 

• Specify  which  devices  in  the  control  system  should  reside  on  the  Ethernet  LAN. 

• Specify  the  transmission  medium  option  that  is  to  be  used.  If  more  than  one  will 
be  used,  indicate  which  one  is  to  be  used  where,  and  the  devices  that  are  to  be 
connected.  If  hubs  are  needed,  specify  the  number  of  ports  and  the  kind  of 
medium  for  each  port. 

• Specify  whether  10  Mbps  Ethernet  or  100  Mbps  Ethernet  is  to  be  used. 

6.2.2  ANSI/ATA  878.1,  ARCNET 

ARCNET  (ANSI/ATA  878.1)  is  a LAN  technology  that  is  slower  than  Ethernet  but  it  is 
deterministic,  meaning  that  it  is  possible  to  determine  the  maximum  delay  before  a device  will  be 
able  to  transmit  a message.  ARCNET  has  been  popular  in  some  building  control  product  lines  as 
a relatively  high-speed  network  for  connecting  high-end  controllers  together  and  with 
workstations.  Ethernet  has  gradually  been  diminishing  ARCNET's  popularity  for  this 
application. 

The  newest  generation  of  ARCNET  chips  has  a scaleable  speed  and  can  be  used  with  EIA-485 
signaling.  This  is  becoming  a popular  option  for  use  with  unitary  controllers.  The  key  features  of 
ARCNET  are  summarized  in  Table  6-2. 
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Table  6-1.  Features  of  ARCNET 


Pros 

Cons 

• ANSI  standard 

• deterministic  response 

• variety  of  media  (UTP,  coax,  fiber  optic) 
•fast  (150Kbps  - 7.5Mbps) 

• high  performance  for  medium  cost 

• the  protocol  is  implemented  in  a chip 

• no  special  development  tools 

• single  source  chip 

• distance  limitations 

• too  costly  for  low-end  controllers 

Specifying  ARCNET  LANs 

If  ARCNET  is  being  used  as  a LAN  for  unitary  controller  networks  there  may  be  several 
of  them  in  the  control  system.  The  specifications  need  to  be  clear  for  each  one. 

• Specify  which  devices  in  the  control  system  should  reside  on  the  ARCNET 
LAN. 

• Specify  the  transmission  medium  option  that  is  to  be  used.  If  more  than  one  will 
be  used,  indicate  which  one  is  to  be  used  where  and  the  devices  that  are  to  be 
connected.  If  hubs  are  needed,  specify  the  number  of  ports  and  the  kind  of 
medium  for  each  port 

• Specify  how  ARCNET  addresses  are  to  be  assigned  (see  6.3.1). 

6.2.3  Master-Slave/Token-Passing,  MS/TP 

The  Master-Slave/Token  Passing  protocol  (MS/TP)  was  created  by  ASHRAE  to  meet  the  needs 
of  low-cost  building  controllers  and  is  unique  to  BACnet.  The  MS/TP  protocol  is  implemented 
using  EIA-485  signaling.  MS/TP  can  be  used  in  a master-slave  mode,  a peer-to-peer  token 
passing  mode,  or  a combination  of  the  two.  As  a practical  matter  the  speed  is  limited  to  about  76 
Kbps.  Higher  speeds  are  theoretically  possible  but  they  would  require  a dedicated  chip  for 
reliable  operation.  The  added  complexity  and  cost  would  make  LonTalk  or  ARCNET  better 
choices  at  higher  speeds. 

MS/TP  is  the  lowest  cost  LAN  option  in  BACnet.  It  is  designed  for  implementation  on  standard 
single-chip  microprocessors  without  the  addition  of  outboard  hardware  for  timing  and 
transceiver  interfaces.  The  key  features  of  MS/TP  are  summarized  in  Table  6-3. 
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Table  6-3.  Features  of  MS/TP 


Pros 

Cons 

• ANSI  standard 

• low  cost 

• can  be  implemented  in  single  chip 
microprocessors 

• deterministic  response 

• no  special  development  tools 

• single  media 

• limited  speed  (9.6Kbps  - 76Kbps) 

Specifying  MS/TP  LANs 

MS/TP  LANs  will  generally  be  used  for  unitary  controller  networks  so  there  may  be 
several  of  them  in  the  control  system.  The  specifications  need  to  be  clear  for  each  one. 

• Specify  which  devices  in  the  control  system  should  reside  on  the  MS/TP  LAN. 

• Specify  the  baud  rate  to  be  used. 

• Specify  how  MS/TP  addresses  are  to  be  assigned  and  if  slave  devices  will  be 
used  how  the  address  space  is  to  be  divided  between  slaves  and  masters  (see 
6.3.2). 

6.2.4  EIA-709.1,  LonTaik 

LonTalk  is  a technology  developed  by  the  Echelon  Corporation2.  It  has  recently  been  adopted  as 
an  ELA  standard  for  home  automation  networks.  Like  Ethernet  and  ARCNET,  LonTalk  is 
implemented  in  a special  chip.  LonTalk  provides  the  most  flexibility  in  terms  of  media  options. 
Transceivers  are  available  for  traditional  wired  LANs  (DTP,  coax,  fiber  optic)  as  well  as  wireless 
communication  (radio  frequency  (RF)  and  infrared  (IR) ). 

LonTalk  allows  scaleable  speeds  up  to  1.25  Mbps.  It  is  comparable  to  MS/TP  at  the  low  end, 
though  the  hardware  is  more  costly  in  most  cases,  and  ARCNET  at  the  higher  end  (above  150 
Kbps).  As  the  speed  scales  upward  from  150  Kbps,  ARCNET  is  somewhat  more  attractive  in 
terms  of  hardware  cost 

LonTalk  has  the  unique  distinction  of  being  the  only  BACnet  LAN  technology  that  requires 
special  development  tools.  These  tools  are  only  available  from  Echelon  Corporation. 

The  LonTalk  protocol  is  often  confused  with  LonMark.  They  are  totally  different  things.  Devices 
using  the  LonTalk  protocol  do  not  interoperate  unless  some  additional  constraints  are  added  that 
are  specific  to  the  intended  application  of  the  device.  The  BACnet  application  layer  protocol 


2 Certain  trade  names  and  company  products  are  mentioned  in  the  text  or  identified  in  an  illustration  in  order  to 
adequately  specify  the  equipment  used.  In  no  case  does  such  an  identification  imply  recommendation  or 
endorsement  by  the  National  Institute  of  Standards  and  Technology,  nor  does  it  imply  that  the  products  are 
necessarily  the  best  available  for  the  purpose. 
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defines  these  constraints.  In  BACnet,  LonTalk  is  no  different  than  any  other  LAN  technology  in 
that  it  is  simply  used  to  convey  BACnet  messages  between  devices. 

LonMark  is  the  name  given  to  a set  of  implementer’s  agreements  that  make  use  of  application 
features  of  the  LonTalk  protocol  to  achieve  the  same  goal  of  interoperability.  LonMark  products 
are  not  compatible  with  BACnet.  In  order  to  mix  BACnet  devices  and  LonMark  devices  in  the 
same  control  system,  a gateway  is  required.  It  is  no  different  than  combining  BACnet  devices 
with  devices  using  any  proprietary  communication  protocol  Gateway  issues  are  discussed  in 
section  6.8.  The  key  features  of  LonTalk  are  summarized  in  Table  6-4. 


Table  6-4.  Features  of  LonTalk 


Pros 

Cons 

• variety  of  media  (UTP,  coax,  RF,  IR, 
fiberoptic) 

• scaleable  speed  ( 32K  to  1.25  Mbps ) 

• variety  of  media  (UTP,  coax,  fiber  optic) 

• non-deterministic 

• distance  limitations 

• special  development  tools  required 

• application  size  limited 

Specifying  LonTalk  LANs 

LonTalk  LANs  will  generally  be  used  for  unitary  controller  networks  so  there  may  be 
several  of  them  in  the  control  system.  The  specifications  need  to  be  clear  for  each  one. 

• Specify  which  devices  in  the  control  system  should  reside  on  the  LonTalk  LAN. 

• Specify  the  media,  speed  and  topology  to  be  used. 

• Specify  how  LonTalk  addresses  are  to  be  assigned  (see  6.3.3). 

6.2.5  Point-to-Point,  PTP 

The  BACnet  Point-to-Point  protocol  offers  a way  to  interconnect  individual  devices  or  networks 
using  serial  asynchronous  connections  such  as  provided  by  dial-up  modem-to-modem  links.  The 
devices  on  either  end  of  the  PTP  connection  act  as  "half-routers"  and,  once  the  connection  is 
established,  appear  as  routers  to  devices  on  their  respective  networks.  See  Figure  6-1.  If  it  is 
desired  to  remotely  access  a BACnet  network  via  a dial-up  connection,  PTP  should  be  specified. 

• Specify  that  PTP  shall  be  used  as  the  means  to  attach  to  a BACnet  LAN  via  a dial-up 
connection.  Also  specify  that  the  optional  password  protection  shall  be  provided. 

6.3  Specifying  MAC  Addresses  in  a Consistent  Manner 

Every  device  in  a BACnet  system  has  a media  access  control  (MAC)  address.  The  MAC  address 
is  combined  with  the  network  number  to  uniquely  identify  each  device  for  the  purpose  of 
delivering  a message.  This  is  similar  to  the  way  a street  address  is  combined  with  a city  and  state 
to  address  a letter.  For  Ethernet  networks  a unique  MAC  address  is  assigned  when  the 
communication  chip  is  manufactured.  No  special  address  configuration  is  necessary  for  BACnet 
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devices  using  Ethernet.  For  other  BACnet  LANs,  MAC  addresses  must  be  configured 
specifically  for  each  installation. 

In  a multi-vendor  environment  it  is  important  to  manage  the  assignment  of  these  addresses  to 
ensure  that  there  are  no  duplicates  on  the  same  network.  There  is  no  problem  with  duplicate 
MAC  addresses  on  different  networks,  just  like  there  is  no  problem  with  having  more  than  one 
123  Main  Street  as  long  as  they  are  in  different  cities.  A site- specific  plan  for  assigning  MAC 
addresses  should  be  developed  and  vendors  should  be  required  to  follow  it.  Guidance  on  how  to 
do  this  for  each  of  the  relevant  BACnet  LANs  is  given  below.  It  is  also  important  to  document 
the  assigned  addresses  so  that  future  changes  to  the  system  do  not  cause  conflicts. 

• Specify  that  MAC  addresses  shall  be  assigned  as  designated  by  the  owner. 

• Specify  that  a list  of  all  assigned  MAC  addresses  be  included  in  the  system 
documentation. 

6.3.1  Ethernet  MAC  Addresses 

For  Ethernet  networks  a unique  MAC  address  is  assigned  when  the  communication  chip  is 
manufactured.  No  special  address  configuration  is  necessary  for  BACnet  devices  using  Ethernet. 

6.3.2  ARCNET  MAC  addresses 

The  valid  MAC  addresses  for  BACnet  devices  using  ARCNET  are  1-255  (0  is  reserved  for 
broadcasts).  Thus  there  can  be  at  most  255  ARCNET  devices  on  the  same  network.  If  the 
ARCNET  LAN  is  part  of  an  internetwork,  meaning  that  there  are  two  or  more  networks  in  the 
system,  then  there  must  be  one  or  more  routers.  It  is  a good  convention  to  reserve  particular 
addresses  to  be  used  for  ARCNET  routers.  If  the  ARCNET  LAN  is  directly  connected  to  only 
one  other  network  then  a single  address  is  sufficient.  If  the  ARCNET  LAN  is  a backbone 
network  then  a range  of  addresses  will  be  needed.  Using  the  same  router  addresses  on  every 
ARCNET  LAN  in  the  system  makes  it  easier  to  identify  routers  when  troubleshooting  problems. 
It  may  also  make  it  easier  to  program  controllers  that  need  to  know  the  router’s  address. 

• The  site  addressing  plan  should  reserve  an  address  or  a range  of  addresses  to  be  used  by 
ARCNET  routers.  For  the  case  where  one  router  per  ARCNET  network  is  sufficient,  the 
value  255  is  recommended.  For  the  case  where  more  than  one  router  per  network  will  be 
present,  assigning  addresses  in  decreasing  order  beginning  with  255  is  recommended. 

If  more  than  one  vendor  will  be  providing  ARCNET  devices  that  will  reside  on  the  same 
network  or  if  that  may  be  the  case  in  the  future,  it  is  important  to  ensure  that  duplicate  addresses 
are  not  accidentally  assigned.  One  way  to  do  this  is  to  assign  a range  of  addresses  to  each  vendor. 
The  vendors  can  select  any  address  within  the  assigned  range  but  cannot  use  addresses  outside  of 
their  assigned  range.  All  addresses  used  must  be  documented  so  that  future  changes  can  be 
managed. 

• The  site  addressing  plan  should  reserve  a range  of  addresses  for  each  vendor.  It  is 
recommended  that  ranges  begin  with  the  smallest  address  that  is  not  in  a previously 
assigned  range. 
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6.3.3  MS/TP  MAC  addresses 


The  valid  MAC  addresses  for  BACnet  devices  using  MS/TP  are  0-254  (255  is  reserved  for 
broadcasts).  Thus  there  can  be  at  most  255  MS/TP  devices  on  the  same  network.  There  is  an 
additional  constraint  because  the  address  space  is  divided  between  master  devices  and  slave 
devices.  Addresses  128-254  are  reserved  for  slaves.  Addresses  0-127  are  valid  for  both  masters 
and  slaves.  The  portion  of  the  address  space  that  is  actually  used  for  masters  in  a particular 
installation  is  determined  by  the  value  of  the  Max_Master  property  of  the  Device  object. 

The  MS/TP  LAN  was  designed  for  connecting  low-cost  controllers  typically  used  for  unitary  or 
application  specific  controllers.  It  should  not  be  used  as  a backbone  LAN  so  that  there  should  be 
at  most  one  router  to  other  LANs  in  the  system.  A router  must  be  a master.  It  is  recommended 
that  MAC  address  0 be  reserved  for  use  by  the  MS/TP  router. 

• The  site  addressing  plan  should  reserve  the  address  0 for  use  with  MS/TP  routers. 

If  more  than  one  vendor  will  be  providing  MS/TP  devices  that  will  reside  on  the  same  network 
or  if  that  may  be  the  case  in  the  future,  it  is  important  to  ensure  that  duplicate  address  are  not 
accidentally  assigned.  One  way  to  do  this  is  to  assign  a range  of  addresses  to  each  vendor.  This 
applies  to  both  master  addresses  and  slave  addresses.  The  vendor  can  select  any  address  within 
the  assigned  range  but  cannot  use  addresses  outside  of  their  assigned  range.  All  addresses  used 
must  be  documented  so  that  future  changes  can  be  managed. 

• The  site  addressing  plan  should  reserve  a range  of  master  addresses  and  slave  addresses 
for  each  vendor  as  appropriate.  It  is  recommended  that  ranges  begin  with  the  smallest 
address  that  is  not  in  a previously  assigned  range. 

The  address  space  in  the  range  0-127  should  be  apportioned  between  masters  and  slaves 
according  to  the  needs  of  the  system.  If  Max_Master  is  writable  using  BACnet  services,  there  is 
an  advantage  to  assigning  the  smaller  addresses  first  and  configuring  Max_Master  to  the  highest 
address  actually  used  instead  of  using  the  default  value  of  127.  This  it  true  even  if  none  of  the 
address  space  will  be  used  for  slave  devices.  This  approach  will  reduce  the  amount  of  time  used 
to  search  for  new  stations  that  have  entered  the  network  and  increase  the  bandwidth  available  for 
normal  communication.  If  more  master  devices  are  added  to  the  network  at  a later  time  it  would 
be  necessary  to  update  the  value  of  Max_Master  in  each  of  the  master  devices. 

6.3.4  LonTalk  MAC  addresses 

Like  Ethernet,  LonTalk  neuron  chips  are  manufactured  with  a unique  address  or  Neuron_ID. 
Other  addressing  schemes  can  also  be  used  that  are  based  on  (domain,  subnet,  node) 
configurations  or  (domain,  group,  member)  configurations.  If  the  Neuron_ID  is  to  be  used  as  the 
sole  means  of  addressing  for  these  devices  no  additional  configuration  is  necessary.  If  one  of  the 
other  addressing  schemes  is  to  be  used  then  the  owner  needs  to  create  and  impose  constraints  to 
ensure  that  addresses  are  not  duplicated. 
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6.4  Network  Numbering  Conventions 

A BACnet  control  system  can  contain  up  to  65,535  interconnected  networks.  This  provides  great 
flexibility  for  integrating  the  control  systems  in  separate  buildings.  The  ability  to  interconnect 
buildings  provides  opportunities  for  aggregating  and  managing  utility  loads  in  a deregulated 
utility  environment,  remote  maintenance  support,  and  centralized  collection  of  energy 
performance  data. 

BACnet  requires  that  each  network  in  a system  be  assigned  a unique  network  number.  This 
means  that  if  separate  buildings  are  to  be  connected  the  assignment  of  network  numbers  must  be 
managed  so  that  no  duplicate  numbers  occur.  A GSA-wide  plan  for  assigning  network  numbers 
should  be  developed  and  vendors  should  be  required  to  follow  it. 

• Specify  that  network  numbers  shall  be  assigned  as  designated  by  the  owner. 

The  recommended  approach  for  assigning  network  numbers  is  to  allow  each  region  to  use  the 
entire  network  number  domain  within  that  region.  The  region  would  assign  a range  of  numbers 
to  each  building.  The  people  directly  responsible  for  the  building  would  subdivide  this  range  in  a 
manner  appropriate  to  the  building.  For  example,  the  division  could  be  by  network  technology, 
by  floor,  or  by  wing.  An  example  may  make  this  idea  clearer. 

Consider  a region  where  there  are  no  more  than  655  buildings.  The  network  number  domain 
could  be  divided  as  follows: 

BBBFF 

where:  BBB  - a number  between  1 and  655  assigned  to  each  building 
FF  = 00  for  the  building  backbone  network 
FF  = 1-35  indicating  the  floors  or  separate  systems  in  the 
building 

Note  that  the  network  numbers  in  the  range  where  BBB  = 000  are  not  assigned.  These  network 
numbers  might  be  reserved  for  special  purposes,  such  as  temporary  dial-up  connections. 

If  a region  has  more  than  655  buildings  or  has  buildings  with  more  than  35  floors  then  it  might 
be  necessary  to  sub-divide  the  region  and  use  an  entire  network  number  domain  for  each  sub- 
region. 

The  consequence  of  these  separate  domains  is  that  it  will  not  be  possible  to  integrate  buildings 
that  are  in  separate  domains  without  using  some  additional  mechanism  to  make  the  network 
numbers  unique.  This  could  be  done  if  the  central  management  site  uses  BACnet/IP  to  connect  to 
each  domain.  By  assigning  each  domain  to  a separate  IP  port  it  would  become  possible  to 
distinguish  otherwise  identical  network  numbers.  This  would  allow  a central  facility  to 
communicate  with  all  of  the  buildings  but  each  building  would  only  be  able  to  communicate 
directly  with  devices  that  are  within  the  same  domain. 

GSA  already  maintains  a nation-wide  database  of  buildings  that  includes  a numbering  system  to 
uniquely  identify  each  building.  This  numbering  system  has  a range  that  is  too  large  be  used 
directly  for  assigning  BACnet  network  numbers.  For  each  region  or  sub-region  that  has  a 
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separate  BACnet  network  domain,  a mapping  should  be  created  to  link  the  GSA  building  number 
with  the  range  of  BACnet  network  numbers  that  are  assigned  to  that  building. 

It  is  important  to  note  that  any  network  number  management  approach  that  guarantees  each 
network  has  a unique  number  meets  the  requirements  of  BACnet. 

6.5  Device  Object  Identifier  Conventions 

A BACnet  control  system  can  contain  up  to  4,194,305  devices.  This  constraint  comes  from  the 
fact  that  each  device  must  have  a unique  value  for  the  Object_Identifier  property  of  the  Device 
object.  This  uniqueness  is  the  basis  for  BACnet  services  that  permit  dynamic  location  of 
information  and  binding  of  addresses  (the  process  of  determining  how  to  address  a message  in 
order  to  communicate  with  a particular  device). 

In  a multi-vendor  and/or  multi-building  environment  the  assignment  of  the  Device 
Object_Identifier  value  for  each  device  must  be  managed  so  that  no  duplicate  numbers  occur.  A 
GSA-wide  plan  for  assigning  Device  Object_Identifier  values  should  be  developed  and  vendors 
should  be  required  to  follow  it. 

♦ Specify  that  Device  Object_Identifier  properties  shall  be  assigned  values  as  designated  by 
the  owner. 

The  recommended  approach  for  assigning  Device  Object_Identifier  values  is  to  make  use  of  the 
unique  building  numbers  used  to  manage  network  numbers  (the  BBB  field  in  the  example 
above).  In  a given  building  the  object  identifier  would  end  with  the  assigned  building  number. 
The  remainder  of  the  identifier  number  space  would  be  divided  in  a manner  appropriate  to  the 
building.  An  example  of  how  this  might  work  is  as  follows: 

XXFFBBB 

where:  XX  = a number  in  the  range  00-40 

FF  = 00  for  the  building  backbone  network 
FF  =1-35  indicating  the  floors  or  separate  systems  in  the 
building 

BBB  = a number  between  1 and  655  assigned  to  each  building 

For  ARCNET  and  MS/TP  networks  the  XX  field  could  also  be  used  to  assign  the  MAC  address. 
See  6.3. 

This  management  approach  has  the  advantage  of  providing  a great  deal  of  information  to 
someone  troubleshooting  communication  problems  because  the  physical  location  of  the  device 
can  be  deduced  from  the  Object_Identifier  property  of  the  Device  object.  It  also  makes  many 
valid  Object_Identifier  values  unusable  because  they  don’t  fit  into  the  template.  In  this  example, 
at  most  41  devices  could  be  present  on  each  network  for  a total  of  1,476  in  the  entire  building.  If 
the  building  does  not  use,  and  will  never  use  all  36  networks,  then  the  number  space  for  unused 
networks  can  be  added  to  existing  networks  to  get  around  the  limitation  of  41  devices  per 
network. 
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This  would  work  fine  for  many  buildings  but  may  be  too  restrictive  for  very  large  buildings.  If 
the  XX  and  FF  fields  were  combined  into  one  range  that  was  assigned  serially  as  devices  were 
installed,  the  total  number  of  possible  BACnet  devices  increases  to  4,195  and  they  could  be 
arbitrarily  assigned  to  different  networks.  These  kinds  of  decisions  can  be  made  on  a building- 
by-building  basis.  The  critical  factor  is  that  the  range  of  possible  values  be  restricted  to  a set  that 
will  never  conflict  with  assignments  made  in  other  buildings  in  the  same  network  domain. 

6.6  Use  of  BACnet  with  the  Internet  Protocols 

BACnet  provides  two  distinct  ways  that  messages  can  be  conveyed  across  internets  that  use  IP, 
the  Internet  Protocol.  By  means  of  these  techniques,  wide  area  BACnet  internetworks  can  be 
created  that  span  the  country  or  the  globe. 

6.6.1  Annex  H Tunneling  Routers 

BACnet  Tunneling  Routers  (BTR)  are  devices  that  appear  as  traditional  routers  to  the  devices 
that  are  on  the  same  LAN  as  the  BTR  but  use  IP  to  communicate  with  peer  BTRs  on  distant 
LANs.  This  is  accomplished  by  configuring  routing  tables  in  each  BTR  that  consist  of  (BACnet 
Network  Number,  IP  Address)  pairs.  The  mechanism  is  illustrated  in  Figure  6-3. 

The  use  of  BTRs  is  relatively  inexpensive  and  has  the  advantage  that  the  individual  BACnet 
devices  need  not  themselves  be  "IP  literate."  In  other  words,  BTRs  can  be  used  with  existing 
BACnet  networks  that  also  have  a connection  to  an  IP  internet,  intranet,  or  the  Internet  with  a 
capital  "I". 
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Figure  6-3.  An  IP  Connection  using  Annex  H Tunneling  Routers 
6.6.2  Addendum  135a,  BACnet/IP 


In  the  case  of  BACnet/IP,  the  addendum  to  BACnet  adopted  in  January  1999,  the  individual 
BACnet  devices  themselves  are  IP-capable.  Thus  no  tunneling  routers  are  needed  and  the  devices 
can  communicate  among  themselves  directly.  A problem  arises,  however,  when  it  is  necessary  to 
convey  broadcast  messages  from  one  IP  subnet  to  another  since  most  IP  routers  do  not  pass  such 
messages.  To  get  around  this,  BACnet/IP  specifies  the  use  of  a device  called  a "BACnet 
Broadcast  Management  Device"  (BBMD).  A BBMD  acts  essentially  like  a BTR  but  only  for 
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broadcast  messages.  BACnet/IP  also  specifies  how  IP  multicasting  can  be  used  to  propagate 
broadcasts  if  the  IP  routers  support  it.  Multicasting  eliminates  the  need  for  BBMDs. 

A 


B 

Figure  6-4.  BACnet/IP  Devices  Communicate  with  Each  Other  Directly 


Note  in  Figure  6-4  devices  A and  B are  on  the  same  BACnet  network  even  though  they  are  on 
different  IP  subnets.  Thus  multiple  IP  subnets  can  be  combined  to  form  a single  BACnet 
network.  BACnet/IP  also  allows  "foreign  devices,"  i.e.,  devices  not  on  the  same  subnet  with  any 
of  the  other  BACnet  devices,  to  "join"  the  BACnet  internet.  This  capability  will  prove  useful  for 
workstations  that  have  internet  access  but  are  remote  from  the  site  where  the  BACnet  devices  are 
located. 
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• Specify,  if  existing  BACnet  non-IP  devices  are  to  be  interconnected  via  an  IP  network, 
that  BACnet  Tunneling  Routers  conforming  to  Annex  H shall  be  provided. 

• Specify,  for  new  networks  which  need  IP  connectivity,  that  devices  shall  be  provided 
that  conform  to  Addendum  135a,  BACnet/IP.  For  broadcast  distribution,  BBMDs  shall 
also  be  provided  or  appropriate  arrangements  made  for  the  use  of  IP  multicasting. 

6.7  Routers  - Interconnecting  Multiple  BACnet  Networks 

Routers  in  BACnet  are  used  for  two  distinct  purposes.  The  first  is  to  join  together  networks  that 
use  different  LAN  technologies,  e.g.,  a BACnet  Ethernet  LAN  to  a BACnet  MS/TP  LAN.  The 
second  is  to  join  together  networks  that  use  the  same  technology  but  have  exhausted  their  supply 
of  MAC  addresses.  An  example  of  this  would  be  a router  that  connects  two  ARCNET  LANs, 
each  of  which  can  have  at  most  only  255  devices.  Several  items  should  be  specified. 

• Specify  that  it  shall  be  the  contractor's  responsibility  to  configure  each  router  using  the 
network  numbering  scheme  agreed  to  for  the  project. 

• Specify  that  each  router  shall  be  configured  such  that  all  network  layer  error  messages 
shall  be  directed  to  a specific  workstation  using  the  BACnet  ConfirmedTextMessage 
service. 

• Specify  that  it  shall  be  the  contractor's  responsibility  to  initially  configure  each  router 
with  routing  tables  containing  all  network  numbers  that  are  part  of  the  project's  internet. 

• Specify  that  the  router  shall  be  able  to  receive  messages  at  each  port  of  any  length  that 
is  valid  for  the  LAN  technology  connected  to  that  port,  and  to  forward  the  message  to 
any  directly-connected  network  that  can  convey  a message  of  that  size. 

6.8  Message  Segmentation 

Message  traffic  data  collected  from  operating  BACnet  systems  indicate  that  the  most  commonly 
used  BACnet  messages  are  smalL  However,  it  is  sometimes  desirable  to  be  able  to  exchange 
large  messages.  For  example,  uploading  and  downloading  a device's  database  and  programs  may 
require  the  exchange  of  considerable  information. 

A manufacturer  may  choose  to  restrict  the  message  buffer  size  in  a device  as  a way  to  optimize 
memory  resources.  Under  these  circumstances  it  may  become  necessary  to  support  message 
segmentation  in  order  to  exchange  large  messages.  LAN  technologies  also  impose  constraints  on 
maximum  message  sizes.  A consistent  policy  on  message  sizes  and  segmentation  is  needed  to 
insure  interoperability  in  multi- vendor  systems. 

• Specify  that  all  BACnet  devices  shall  support  the  reception  of  messages  up  to  the 
largest  size  permitted  by  the  LAN  technology  or  support  reception  of  segmented 
messages. 
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• Specify  that  all  BACnet  devices  shall  support  the  transmission  of  messages  up  to  the 
largest  size  permitted  by  the  LAN  technology  or  support  transmission  of  segmented 
messages. 

• Specify  that  all  workstations  shall  support  both  segmented  message  transmission  and 
segmented  message  reception. 

• Specify  that  all  BACnet  Building  Controllers  (see  B.2)  shall  support  both  segmented 
message  transmission  and  segmented  message  reception. 

6.9  Gateways  - Connecting  to  Legacy  Systems 

In  some  retrofit  projects  it  is  not  economically  viable,  or  necessary,  to  replace  the  entire  building 
control  system  at  one  time.  Expansion  or  replacement  of  the  system  may  take  place  in  stages. 
Under  these  circumstances  it  is  necessary  to  find  a way  to  connect  the  remaining  legacy 
controllers  with  the  new  BACnet  controllers.  This  is  accomplished  by  using  a device  called  a 
"gateway."  A gateway  is  a device  that  translates  between  BACnet  and  the  non-BACnet 
communication  protocol 

Computers  require  precise,  rigidly  defined  rules  or  protocols  for  communication.  Protocol 
translation,  like  language  translation,  is  an  imperfect  art.  Concepts  that  are  easy  to  express  in  one 
language  or  protocol  may  be  difficult  or  even  impossible  to  translate  into  another.  Gateways 
usually  provide  access  to  only  a subset  of  the  information  that  is  available  in  the  non-BACnet 
system  Complicated  tasks  such  as  scheduling  and  alarm  processing  may  not  be  possible  at  all. 
For  these  reasons  gateways  should  be  avoided  when  possible  and  when  they  are  necessary  their 
capabilities  and  performance  must  be  clearly  specified. 

Which  devices  can  communicate  with  each  other? 

Gateways  do  not  necessarily  permit  any  arbitrary  pair  of  devices  to  communicate  with 
each  other.  For  example,  a workstation  could  be  capable  of  connecting  to  a BACnet  LAN 
and  also  to  a non-BACnet  LAN  and  provide  the  operator  with  access  to  information  from 
both  systems.  This  approach  may  not  allow  communication  between  the  BACnet 
controllers  and  the  non-BACnet  controllers. 

• Specify  that  the  operator  workstation  shall  display  information  from  both  the 
BACnet  and  non-BACnet  devices.  If  appropriate,  specify  which  other  devices 
should  also  be  able  to  communicate  through  the  gateway. 

Uni-directional  or  bi-directional  communication? 

Gateways  may  be  uni-directional,  meaning  that  a BACnet  device  can  access  information 
from  a non-BACnet  device  but  the  non-BACnet  devices  cannot  access  information  from 
BACnet  devices.  The  reverse  is  also  possible  where  a non-BACnet  device  can  access 
information  from  BACnet  devices  but  BACnet  devices  cannot  access  information  from 
the  non-BACnet  devices.  Gateways  may  also  be  bi-directionaL 
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• Specify  which  way  information  must  flow  through  the  gateway  or  that  the 
gateway  should  provide  bi-directional  communication. 

Which  points  are  readable? 

Gateways  have  a limited  capacity.  Not  all  information  contained  in  the  systems  being 
interconnected  is  necessarily  accessible  through  the  gateway. 

• Specify  which  non-BACnet  points  are  to  be  readable  from  the  BACnet  side  of 
the  gateway  and  which  BACnet  objects  are  to  be  readable  from  the  non-BACnet 
side  of  the  gateway. 

Which  points  are  changeable? 

The  ability  to  view  information  through  the  gateway  does  not  imply  an  ability  to  make 
changes  or  to  command  actions  through  the  gateway. 

• Specify  which  non-BACnet  points  are  to  be  modifiable  from  the  BACnet  side  of 
the  gateway  and  which  BACnet  objects  are  to  be  modifiable  from  the  non- 
BACnet  side  of  the  gateway. 


Expansion 

Control  systems  tend  to  change  over  time.  A gateway  needs  to  be  able  to  accommodate 
foreseeable  control  system  changes. 

• Specify  how  much  expansion  capacity  is  required  in  the  gateway. 

Archiving  controller  programs  and  configuration  databases 

Many  control  systems  provide  a way  to  archive  control  programs  and  configuration 
databases  by  uploading  the  pertinent  files  from  the  controller.  These  archives  can  be  used 
to  restore  the  controller  to  a known  configuration  in  the  event  of  an  equipment  failure. 
Gateways  may  not  be  capable  of  transferring  this  kind  of  information. 

• Specify  how  controller  program  and  configuration  database  archives  are  to  be 
created  and  maintained. 


Trending 

The  collection  of  trend  data  is  handled  in  many  different  ways  in  proprietary  control 
systems.  A gateway  may  permit  a workstation  to  access  the  points  that  need  to  be  trended 
but  may  not  be  able  to  transfer  trend  log  files  that  are  created  by  a controller.  It  is 
important  to  understand  the  trending  capabilities  of  the  legacy  system  and  to  ensure  that 
the  gateway  has  the  necessary  capability  to  support  the  trending  needs  of  the  application. 
For  additional  information  about  trending  see  3.4. 
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• Specify  any  gateway  features  that  will  be  needed  to  support  collection  of  trend 
data. 


Scheduling 

The  methods  used  to  schedule  control  system  actions  are  handled  in  many  different  ways 
in  proprietary  control  systems.  If  the  scheduling  needs  of  the  facility  require  passing 
schedule  information  through  the  gateway,  this  capability  must  be  specified.  For  more 
information  about  scheduling  see  3.3. 

• Specify  any  gateway  features  that  will  be  needed  to  support  scheduling. 

Alarm  and  Event  Handling 

The  detection,  notification,  and  acknowledgment  of  alarms  and  other  events  are  handled 
in  many  different  ways  in  proprietary  control  systems.  It  is  important  to  understand  the 
alarm  and  event  handling  capabilities  of  the  legacy  system  and  to  ensure  that  the  gateway 
has  the  necessary  capability  to  support  any  needed  alarm  and  event  processing  hi  the 
integrated  system. 

• Specify  any  gateway  features  that  will  be  needed  to  support  the  detection, 
notification,  and  acknowledgment  of  alarms  and  other  significant  events. 

7 Practical  Considerations  in  the  Construction  of  BACnet  Systems 

Several  key  issues  directly  affect  the  successful  implementation  and  operation  of  a BACnet- 
based  building  automation  system  These  issues  can  be  classified  according  to  the  phases  of  any 
construction  project  - from  procurement  through  construction  and  ongoing  operations  and 
maintenance.  In  the  sections  that  follow,  some  general  guidelines  and  recommendations  are 
offered  to  assist  the  BAS  project  team  in  the  procurement,  construction,  commissioning,  and 
operation/maintenance  phases  of  a BAS  project. 

7.1  Procurement  Phase 

A successful  BAS  implementation  requires  a careful  vendor  procurement  process.  The  end 
product  of  a control  system  design  should  be  a complete  set  of  construction  documents.  The 
construction  documents  referred  to  here  include  the  Request  for  Proposal  (RFP)  and  the  project’s 
Technical  Specifications. 

The  RFP  document  serves  as  the  vendor's  overview  of  the  project,  a set  of  instructions  for 
bidding  the  project,  and  the  specifying  engineer’s  tool  to  evaluate  competing  BAS  solutions. 
Therefore,  there  are  several  items  that  must  be  included  in  this  document  in  order  to  ensure 
interoperability  via  BACnet,  and  to  avoid  misunderstandings  and  future  implementation 
problems. 

As  previously  stated,  BACnet  enables  multi- vendor  interoperability  but  in  and  of  itself,  does  not 
require  that  multiple  vendors  participate  in  any  given  BAS  project.  If  the  project  requires  a multi- 
vendor environment,  special  attention  should  be  made  in  the  RFP  to  clearly  define  each  scope  of 
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work  along  with  its  respective  deliverables.  In  the  process  of  this  definition,  the  overall  system 
design  should  be  referenced  to  ensure  that  all  system  components  (hardware  and  software)  are 
accounted  for  within  the  individual  scopes  and  to  ensure  that  there  is  no  overlap. 

In  order  to  ensure  interoperability,  the  RFP  should  require  the  controls  vendor  to  submit  a 
description  of  the  proposed  system.  This  description  should  define  the  system  architecture  and 
explicitly  identify  “where  and  how”  BACnet  is  to  be  implemented.  At  a minimum,  the  RFP 
should  require  that  the  description  include  the  following  items: 

• Narrative  providing  an  overview  of  the  BAS  system,  primary  components,  workstation(s), 
and  LAN  architecture 

• Identification  of  any  clarifications  or  exceptions  to  the  project  specifications 

• A listing  and  quantification  of  all  microprocessor-based  BAS  equipment  to  be  supplied  and 
associated  information  “cut-sheets”  for  each 

• A listing  of  references,  as  appropriate,  for  projects  of  a similar  nature  to  the  proposed  BAS 

• The  option  of  requesting  a formal  BAS  demonstration  at  either  the  vendor’s  local  offices  or 
customer  location 

In  addition  to  the  system  description,  a completed  "Vendor  Qualifications  Form"  should  be 
developed.  As  part  of  this  form,  the  vendor  should  be  required  to  provide  information  on  local 
office  staffing,  spare  parts  inventory,  and  the  number  of  locally  installed  BACnet  systems  with 
references. 

With  the  above  information,  the  specifying  engineer  can  ensure  the  vendor  understands  the 
requirements  of  the  project,  has  sufficient  experience,  and  has  proposed  a system  that  adheres  to 
the  Technical  Specifications.  If  alternative  approaches  are  provided  in  one  or  more  exceptions  to 
the  specifications  they  must  be  carefully  reviewed  to  determine  whether  or  not  they  meet  the 
project  needs. 

7.2  Construction  Phase 

After  the  controls  vendor(s)  are  selected  and  the  project  is  awarded,  the  submittals  phase  of 
construction  begins.  As  part  of  the  submittal  review  process,  the  control  vendor(s)  should  be 
required  by  the  Technical  Specification  to  submit  several  key  items  to  ensure  interoperability. 
These  items  include  a Protocol  Implementation  Conformance  Statement  (PICS)  and  detailed 
points  lists.  Coordination  issues  between  the  vendor(s)  and  Owner  also  require  special 
consideration. 

7.2.1  Protocol  Implementation  Conformance  Statements  (PICS) 

As  part  of  the  vendor's  submittal  package,  a PICS  should  be  submitted  for  each  BACnet  device 
in  the  system.  At  a minimum,  the  PICS  should  demonstrate  the  device's  BACnet  capability  by 
listing  the  following  items: 
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1.  BACnet  Standard  Application  Services  Supported  - This  table  confirms  the  BACnet  services 
supported  by  the  device.  Refer  to  Annex  A for  detailed  descriptions  of  these  services. 

2.  Standard  Object  Types  Supported  - This  table  lists  the  device's  supported  object  types  as 
listed  in  Section  4.2.  It  also  indicates  if  the  object  is  dynamically  creatable,  dynamically 
deletable,  optional  supported  properties,  and  writable  properties. 

3.  Data  Link  Layer  Options  - Describes  the  network  types  supported  for  communications,  e.g., 
Ethernet,  ARCNET,  or  MS/TP. 

4.  Special  Functionality  - Describes  any  special  exceptions  the  device  may  have  to  the  BACnet 
protocol  in  order  to  perform  any  specific  function. 

5.  Property  Range  Restrictions  - Indicates,  among  other  things,  the  number  of  characters 
allowed  for  the  various  text  properties,  such  as  Object_Name  and  Description. 

The  BACnet  requirements  of  the  Technical  Specifications  should  act  as  the  submittal  review 
criteria.  The  information  provided  by  the  PICS  should  be  compared  to  the  Technical 
Specifications  to  ensure  the  device  will  function  in  the  system  as  intended  by  the  design. 

7.2.2  Points  Lists 

The  controls  vendor(s)  should  also  provide  a detailed  points  lists  for  the  system.  In  addition  to 
standard  I/O  information,  these  points  lists  should  contain  the  following  items  to  ensure  BACnet 
interoperability: 

• Proposed  I/O  Names  - An  I/O  point  naming  convention  should  be  specified  in  the  Technical 
Specifications  in  order  to  identify  clearly  system  points.  Verification  of  the  vendor’s 
proposed  naming  schemes  should  be  performed. 

• BACnet  Object  Description  - This  description  includes  the  Object  ID  and  Device  ID  for  each 
I/O  point.  In  a multi- vendor  environment,  special  care  should  be  taken  to  ensure  that  no 
device  ID's  are  duplicated.  Also,  non-standard  BACnet  objects  and  properties  should  be 
documented  including  their  structure  and  data  types. 

7.2.3  Coordination 

Successful  BACnet  interoperability  also  depends  on  the  interaction  between  vendors,  in  a multi- 
vendor environment,  and  between  the  vendor(s)  and  owner.  To  ensure  this  process  takes  place 
both  effectively  and  proactively,  the  vendor  should  produce  a coordination  action-list  that 
identifies  all  BACnet-related  information  requirements  (e.g.,  each  BAS  vendor  involved,  HVAC 
equipment  interfaces,  owner  LAN/WAN  coordination,  etc.),  responsible  parties,  contact  names, 
and  critical  dates.  This  action-list  should  be  reviewed  and  updated  at  all  BAS-related  progress 
meetings. 
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7.3  Commissioning  Phase 


During  the  commissioning  phase,  each  control  sequence  should  be  verified  along  with  the 
functionality  of  each  workstation  component  including  graphics,  reports,  trend  logs,  and  so  on. 
In  order  to  verify  the  operation  of  the  BACnet  communications,  insofar  as  it  relates  to  functions 
above,  it  may  prove  useful  to  make  use  of  a "protocol  analyzer"  to  observe  the  message  flow  and 
content  on  the  network.  A protocol  analyzer  is  a computer  that  can  intercept  messages  on  the 
communication  medium  and  display  their  contents  in  an  easy-to-understand  format.  Obviously 
knowledge  of  the  BACnet  protocol  is  a prerequisite  to  interpreting  the  captured  network  traffic. 
BACnet  protocol  analyzers  are  available  from  NIST  in  the  form  of  "Visual  Test  Shell"  software 
and  also  from  at  least  one  commercial  vendor.  The  analyzer  software  can  be  installed  on  a 
portable  laptop  computer  or  on  a system  workstation,  whichever  is  most  convenient. 

With  a protocol  analyzer  an  operator  can  verify  that  alarm  messages  are  being  directed  to  the 
proper  recipients;  that  change-of- value  notifications  are  being  correctly  produced;  that  time 
synchronizations  are  sent  at  the  correct  intervals;  and  so  on.  Also,  if  there  is  a particular  problem 
that  needs  to  be  fixed,  the  protocol  analyzer  can  be  set  to  "trigger"  its  data  capture  based  on  a 
specific  message,  source  device,  destination  device,  time  of  day,  or  other  defined  condition. 
Likewise,  the  captured  data  can  be  filtered  to  eliminate  messages  that  are  not  relevant  to 
resolving  the  problem  at  hand.  Experience  has  shown  that  most  operational  problems  relate  to 
improper  device  configuration  or  programming.  In  such  cases,  the  use  of  a protocol  analyzer  can 
often  pinpoint  the  cause  of  a problem  within  minutes. 

When  a project  involves  the  expansion  of  an  existing  BACnet  system,  it  is  important  to  note  that 
the  vendor  providing  the  new  equipment  may  not  be  the  same  vendor  that  provided  the  operator 
workstation.  It  is  important  to  have  someone  present  during  commissioning  who  understands  the 
details  of  the  workstation  set-up  and  configuration. 

7.4  Operation  and  Maintenance  Phase 

After  commissioning  and  acceptance,  ownership  of  the  system  is  transferred  from  the  controls 
vendor(s)  to  the  owner.  There  are  several  Operation  and  Maintenance  (O  & M)  issues  that  must 
be  addressed  before  this  transfer  occurs  and  as  an  on-going  process  throughout  the  life  of  the 
system  that  will  effect  future  expansion  and  interoperability  of  the  system. 

7.4.1  Record  Documentation 

Before  system  acceptance  occurs  (and  release  of  final  retainage),  the  owner  should  be  in 
possession  of  a complete  set  of  record  documentation  including  the  following: 

• "As-built"  record  drawings  - Schematic  drawings  that  represent  the  final  system  architecture, 
configuration,  and  input/output  (I/O)  points. 

• I/O  Points  List  - The  I/O  listings  should  include  the  name/description,  display  units,  alarm 
limit(s)/definition,  and  BACnet  object  description,  including  Object  ID  and  Device  ID,  for 
each  I/O  point. 
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• Non-Standard  BACnet  Objects  - Documentation  for  any  non-standard  BACnet  objects, 
properties,  or  enumerations  utilized  detailing  their  structure,  data  types,  and  any  associated 
lists  or  enumerated  values. 

• Program  records  - Complete  program  descriptions  of  all  control  and  application  software  per 
the  system  installation.  This  should  include  English  narratives  of  control/application 
programs,  flowcharts  and  actual  source  code/files. 

As  hardware  and/or  software  modifications  are  made  to  the  system,  these  records  must  be 
updated  to  reflect  the  current  operating  conditions  of  the  system  As  future  expansion  needs 
arise,  the  owner  will  be  able  to  competitively  bid  out  the  work  to  controls  vendors  and  provide 
them  with  the  record  documentation  in  order  to  ensure  that  the  expansion  will  operate  with  the 
existing  system 

7.4,2  Operator  Training 

Operator  training  becomes  an  integral  part  of  BACnet  interoperability  when  considering  the 
expansion  of  an  existing  BACnet  system  This  process  begins  at  the  design  phase  when  training 
requirements  are  specified  in  the  Technical  Specifications.  The  specifying  engineer  should 
include  the  following  items  in  order  to  ensure  that  the  operating  personnel  receive  complete 
system  training  and  are  fully  capable  of  operating  and  maintaining  the  system 

• Minimum  Training  Hours  - Specify  the  minimum  number  of  hours  required  by  the  controls 
vendor(s)  for  training  of  operator  personnel  This  should  include  on-site  (hand-on)  training  as 
well  as  off-site  (factory)  training. 

• Course  Content  - Specify  the  minimum  course  content  requirements.  In  addition  to  basic 
system  training,  the  content  should  also  include  an  overview  of  the  BACnet  protocol  and 
system  network.  Also  included  in  the  content  should  be  skills  to  enable  the  operator  to  add, 
delete,  and/or  modify  I/O  points  and  create  or  edit  system  tabular  reports  and  graphic 
displays  at  the  Operator  Workstation  (OWS). 

The  owner  and/or  a representative  should  attend  the  training  sessions  to  ensure  that  these  training 
requirements  are  fulfilled.  Such  training  could  potentially  decrease  the  owner's  future  system 
expansion  costs  by  limiting  the  controls  vendor(s)  to  only  installing  and  commissioning  field 
devices  while  the  owner's  operating  personnel  add  and/or  modify  the  system  reports  and  graphics 
at  the  OWS  and  map  the  desired  newly  installed  I/O  points  as  provided  by  the  controls  vendor(s). 
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Annex  A.  BACnet  Interoperability  Building  Blocks  (BIBBs) 

BACnet  Interoperability  Building  Blocks  (BIBBs)  are  collections  of  one  or  more  BACnet 
services.  These  are  prescribed  in  terms  of  an  "A"  and  a "B"  device.  Both  of  these  devices  are 
nodes  on  a BACnet  inter-network.  In  most  cases  the  “A”  device  will  act  as  the  user  of  data  and 
the  “B”  device  will  be  the  provider  of  this  data.  In  addition,  certain  BIBBs  may  also  be 
predicated  on  the  support  of  certain,  otherwise  optional,  BACnet  objects  or  properties  and  may 
place  constraints  on  the  allowable  values  of  specific  properties  or  service  parameters. 

A.1  Data  Sharing  BIBBs 

These  BIBBs  prescribe  the  BACnet  capabilities  required  to  interoperably  perform  the  data 
sharing  functions  enumerated  in  3.1  for  the  BACnet  devices  defined  therein. 

A.1.1  BIBB  - Data  Sharing- ReadProperty- A (DS-RP-A) 

The  A device  is  a user  of  data  from  device  B. 


BACnet  Service 

Initiate 

Execute 

ReadProperty 

X 

A.  1.2  BIBB  - Data  Sharing- ReadProperty-B  (DS-RP-B) 

The  B device  is  a provider  of  data  to  device  A. 


BACnet  Service 

Initiate 

Execute 

ReadProperty 

X 

A. 1.3  BIBB  - Data  Sharing-ReadPropertyMultiple-A  (DS-RPM-A) 

The  A device  is  a user  of  data  from  device  B and  requests  multiple  values  at  one  time. 


BACnet  Service 

Initiate 

Execute 

ReadPropertyMultiple 

X 

A.1.4  BIBB  - Data  Sharing- ReadPropertyMultiple-B  (DS-RPM-B) 

The  B device  is  a provider  of  data  to  device  A and  returns  multiple  values  at  one  time. 


BACnet  Service 

Initiate 

Execute 

ReadPropertyMultiple 

X 
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A.  1.5  BIBB  - Data  Sharing- ReadProperty Conditional- A (DS-RPC-A) 


The  A device  is  a user  of  data  from  device  B and  requests  that  values  be  returned  based  upon 
specific  criteria  that  are  contained  in  the  message. 


BACnet  Service 

Initiate 

Execute 

ReadPropertyConditional 

X 

A.  1.6  BIBB  - Data  Sharing-ReadPropertyConditional-B  (DS-RPC-B) ) 

The  B device  is  a provider  of  data  to  device  A based,  conditionally,  upon  the  selection  criteria  in 
the  request  from  device  A. 


BACnet  Service 

Initiate 

Execute 

ReadPropertyConditional 

X 

A.1.7  BIBB  - Data  Sharing-WriteProperty-A  (DS-WP-A) ) 

The  A device  sets  a value  in  device  B. 


BACnet  Service 

Initiate 

Execute 

WriteProperty 

X 

A.  1.8  BIBB  - Data  Sharing- WriteProperty-B  (DS-WP-B) 
The  B device  allows  a value  to  be  changed  by  device  A. 


BACnet  Service 

Initiate 

Execute 

WriteProperty 

X 

A.  1.9  BIBB  • Data  Sharing- WritePropertyMultiple-A  (DS-WPM-A) 
The  A device  sets  multiple  values  in  device  B at  one  time. 


BACnet  Service 

Initiate 

Execute 

WritePropertyMultiple 

X 
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A.  1.10  BIBB  - Data  Sharing- WritePropertyMultiple-B  (DS-WPM-B) 

The  B device  allows  multiple  values  to  be  changed  by  device  A at  one  time. 


BACnet  Service 

Initiate 

Execute 

WritePropertyMultiple 

X 

A.1.11  BIBB  - Data  Sharing-COV-A  (DS-COV-A) 

The  B device  is  a provider  of  COV  data  to  device  A. 


BACnet  Service 

Initiate 

Execute 

SubscribeCOV 

X 

ConfirmedCOVNotification 

X 

UnconfirmedCOVNotification 

X 

Devices  claiming  conformance  to  DS-COV-B  shall  support  a minimum  of  5 simultaneous 
subscriptions. 


A.1.12  BIBB  - Data  Sharing-COV-B  (DS-COV-B) 

The  A device  is  a user  of  COV  data  from  device  B. 


BACnet  Service 

Initiate 

Execute 

SubscribeCOV 

X 

ConfirmedCOVNotification 

X 

UnconfirmedCOVNotification 

X 

A. 1.13  BIBB  - Data  Sharing-COV-Unsubscribed-A  (DS-COVU-A) 
The  A device  processes  unsolicited  COV  data  from  device  B. 


BACnet  Service 

Initiate 

Execute 

UnconfirmedCOVNotification 

X 

A.  1.14  BIBB  - Data  Sharing-COV-Unsubscribed-B  (DS-COVU-B) 

The  B device  generates  unsolicited  COV  notifications. 


BACnet  Service 

Initiate 

Execute 

UnconfirmedCOVNotification 

X 
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A.2  Alarm  and  Event  Management  BIBBs 


1 

1 

I 

These  BIBBs  prescribe  the  BACnet  capabilities  required  to  interoperably  perform  the  alarm  and  H 

event  management  functions  enumerated  in  3.2  for  the  BACnet  devices  defined  therein. 

I 

A.2.1  BIBB  - Alarm  and  Event-Notification- A (AE-N-A)  L 

The  A device  processes  notifications  about  alarms  and  other  events. 

I 
i 

A.2.2  BIBB  - Alarm  and  Event-Notification-B  (AE-N-B) 

Device  B generates  notifications  about  alarms  and  other  events.  [ 

1 

Devices  claiming  conformance  to  AE-N-B  shall  also  support  either  Intrinsic  or  Algorithmic  I 

reporting. 

A.2.3  BIBB  - Alarm  and  Event-ACK-A  (AE-ACK-A) 

Device  A acknowledges  alarm/event  notifications. 


BACnet  Service 

Initiate 

Execute 

AcknowledgeAlarm 

X 

A.2.4  BIBB  - Alarm  and  Event- ACK-B  (AE-ACK-B) 

Device  B processes  acknowledgments  of  previously  transmitted  alarm/event  notifications. 


BACnet  Service 

Initiate 

Execute 

AcknowledgeAlarm 

X 

BACnet  Service 

Initiate 

Execute 

ConfirmedEventNotification 

X 

UnconfirmedEventNotification 

X 

BACnet  Service 

Initiate 

Execute 

ConfirmedEventNotification 

X 

UnconfirmedEventNotification 

X 

In  order  to  support  this  BIBB  the  device  must  also  support  acknowledgeable  alarms. 
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A.2.5  BIBB  - Alarm  and  Event-Summary- A (AE-ASUM-A) 

Device  A requests  summaries  of  alarms  from  device  B. 


BACnet  Service 

Initiate 

Execute 

GetAlarmSummary 

X 

A.2.6  BIBB  - Alarm  and  Event-Summary-B  (AE-ASUM-B) 

Device  B provides  summaries  of  alarms  device  A. 


BACnet  Service 

Initiate 

Execute 

GetAlarmSummary 

X 

A.2.7  BIBB  - Event-Summary- A (AE-ESUM-A) 
Device  A requests  event  enrollments  from  device  B. 


BACnet  Service 

Initiate 

Execute 

GetEnrollmentSummary 

X 

A.2.8  BIBB  - Event-Summary-B  (AE-ESUM-B) ) 
Device  B provides  event  enrollments  to  device  A. 


BACnet  Service 

Initiate 

Execute 

GetEnrollmentSummary 

X 

A3  Scheduling  BIBBs 

These  BIBBs  prescribe  the  BACnet  capabilities  required  to  interoperably  perform  the  scheduling 
functions  enumerated  in  3.3  for  the  BACnet  devices  defined  therein. 


A. 3.1  BIBB  - Scheduling  - A (SCHED-A) 

The  A device  manipulates  schedules  and  calendars  on  the  B device.  The  A device  must  support 
the  DS-RP-A  and  DS-WP-A  BIBBs. 
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A.3.2  BIBB  - Scheduling  - B (SCHED-B) 


The  B device  provides  date  and  time  scheduling  of  the  values  of  specific  properties  of  specific 
objects.  In  addition  to  supporting  the  DS-RP-B  and  DS-WP-B  BIBBs,  each  device  claiming 
conformance  to  SCHED-B  must  also  possess  at  least  one  Calendar,  one  Schedule  object,  and 
one  Command  object.  The  Command  object  is  required  for  scheduling  actions  in  other  devices. 

The  Schedule  object  must  support  at  least  6 entries  per  day  and  at  least  one  entry  in  the 
List_of_Object_Property_Reference  property.  The  Schedule  object  must  support  a non-empty 
Exception_Schedule  property. 

The  Command  object  must  be  capable  of  writing  to  objects  in  other  devices.  The 
Priority_For_Writing  property  in  the  Command  object  must  be  writable. 


A.4  Trending  BIBBs 

These  BIBBs  prescribe  the  BACnet  capabilities  required  to  interoperably  perform  the  trending 
functions  enumerated  in  3.4  for  the  BACnet  devices  defined  therein. 


A.4.1  BIBB  - Viewing  and  Modifying  Trends  - A (T-VMT-A) 

The  A device  displays  trend  data  from  the  B device  and  manipulates  trend  log  collection 
parameters  in  the  B device. 


BACnet  Service 

Initiate 

Execute 

ReadRange 

X 

A.4.2  BIBB  - Viewing  and  Modifying  Trends  - B (T-VMT-B) 

The  B device  collects  the  trend  log  data  records  in  an  internal  buffer.  Each  device  claiming 
conformance  to  T-VMT-B  must  be  able  to  support  at  least  one  Trend  Log  object. 


BACnet  Service 

Initiate 

Execute 

ReadRange 

X 
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A.4.3  BIBB  - Trending  --  Automated  Trend  Retrieval  - A (T-ATR-A) 


The  A device  notifies  the  B device  that  a trending  buffer  has  acquired  a predetermined  number  of 
data  samples. 


BACnet  Service 

Initiate 

Execute 

ConfirmedEventNotification 

X 

ReadRange 

X 

Devices  claiming  conformance  to  T-ATR-A  must  support  the  Trend  Log  object. 


A.4.4  BIBB  - Trending  - Automated  Trend  Retrieval  - B (T-ATR-B) 

The  B device  responds  to  a notification  that  a trend  log  is  ready  with  new  data  and  acquires  the 
new  data  from  the  log. 


BACnet  Service 

Initiate 

Execute 

ConfirmedEventNotification 

X 

ReadRange 

X 

A.5  Device  Management  BIBBs 

These  BIBBs  prescribe  the  BACnet  capabilities  required  to  interoperably  perform  the  device 
management  functions  enumerated  in  3.5  for  the  BACnet  devices  defined  therein. 

A.5.1  BIBB  - Device  Management  - Dynamic  Device  Binding  - A (DM-DDB-A) 

The  A device  seeks  information  about  device  attributes  of  other  devices  and  interprets  device 
announcements. 


BACnet  Service 

Initiate 

Execute 

Who-Is 

X 

I-Am 

X 
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A.5.2  BIBB  - Device  Management  > Dynamic  Device  Binding  - B (DM-DDB-B) 

The  B device  provides  information  about  it’s  device  attributes  and  responds  to  requests  to 
identify  itself. 


BACnet  Service 

Initiate 

Execute 

Who-Is 

X 

I-Am 

X 

A.5.3  BIBB  - Device  Management  - Dynamic  Object  Binding  - A (DM-DOB-A) 

The  A device  seeks  address  information  about  objects. 


BACnet  Service 

Initiate 

Execute 

Who-Has 

X 

I- Have 

X 

A.5.4  BIBB  - Device  Management  - Dynamic  Object  Binding  - B (DM-DOB-B) ) 
The  B device  provides  address  information  about  its  objects  upon  request 


BACnet  Service 

Initiate 

Execute 

Who-Has 

X 

I-Have 

X 

A.5.5  BIBB  ■ Device  Management  • DeviceCommunicationControl  - A (DM-DCC-A) 
The  A device  exercises  communication  control  over  the  B device. 


BACnet  Service 

Initiate 

Execute 

DeviceCommunicationControl 

X 

A.5.6  BIBB  - Device  Management  - DeviceCommunicationControl  - B (DM-DCC-B) ) 
The  B device  responds  to  communication  control  exercised  by  the  A device. 


BACnet  Service 

Initiate 

Execute 

DeviceCommunicationControl 

X 
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A.5.7  BIBB  - Device  Management  - PrivateTransfer  - A (DM-PT-A) ) 


The  A device  initiates  the  transmission  of  non-BACnet  data  within  a BACnet  service  request. 
The  interpretation  of  the  data  is  a local  matter. 


BACnet  Service 

Initiate 

Execute 

ConfirmedPrivateTransfer 

X 

UnconfirmedPrivateTransfer 

X 

A.5.8  BIBB  - Device  Management  - PrivateTransfer  - B (DM-PT-B) ) 

The  B device  processes  the  non-BACnet  data  contained  in  the  BACnet  service  request. 


BACnet  Service 

Initiate 

Execute 

ConfirmedPrivateTransfer 

X 

UnconfirmedPrivateTransfer 

X 

A.5.9  BIBB  - Device  Management  - Text  Message  - A (DM-TM-A) ) 

The  A device  initiates  the  transmission  of  text  messages.  The  interpretation  and  subsequent 
processing  of  the  messages  is  a local  matter. 


BACnet  Service 

Initiate 

Execute 

ConfirmedTextMessage 

X 

UnconfirmedTextMessage 

X 

A.5.10  BIBB  - Device  Management  - Text  Message  - B (DM-TM-B) 

The  B device  processes  the  text  messages. 


BACnet  Service 

Initiate 

Execute 

ConfirmedTextMessage 

X 

UnconfirmedTextMessage 

X 

A.5.11  BIBB  - Device  Management  - TimeSynchronization  - A (DM-TS-A) 

The  A device  provides  time  synchronization  to  B devices.  The  time  parameter  contained  in  the 
service  request  contains  the  date  and  time  as  determined  by  the  clock  in  the  device  issuing  the 
service  request.  Normally  this  will  be  "local  time,"  Le.,  the  time  in  the  local  time  zone  corrected 
for  daylight  savings  time  as  appropriate. 


BACnet  Service 

Initiate 

Execute 

TimeSynchronization 

X 

Devices  claiming  conformance  to  DM-TS-A  must  support  the  Time_Synchronization_Recipients 
property  of  the  Device  object. 
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A. 5.12  BIBB  - Device  Management  • TimeSynchronization  - B (DM-TS-B) ) 
The  B device  interprets  time  synchronization  messages  from  the  A device. 


BACnet  Service 

Initiate 

Execute 

TimeSynchronization 

X 

Devices  claiming  conformance  to  DM-TS-B  must  support  the  Local_Time  and  LocaLDate 
properties  of  their  Device  objects. 


A.5.13  BIBB  - Device  Management  - UTCTimeSynchronization  - A (DM-UTC-A) ) 

The  A device  provides  time  synchronization  to  B devices.  The  time  parameter  contained  in  the 
service  request  contains  "Coordinated  Universal  Time"  (UTC).  For  all  practical  purposes,  UTC 
is  synonymous  with  Greenwich  Mean  Time,  the  time  at  the  zero  or  Greenwich  meridian. 


BACnet  Service 

Initiate 

Execute 

UTCTimeSynchronization 

X 

Devices  claiming  conformance  to  DM-TS-A  must  support  the  Time_Synchronization_Recipients 
property  of  the  Device  object. 

A.5.14  BIBB  - Device  Management  - UTCTimeSynchronization  - B (DM-UTC-B) ) 

The  B device  interprets  time  synchronization  messages  from  the  A device. 


BACnet  Service 

Initiate 

Execute 

UTCTimeSynchronization 

X 

Devices  claiming  conformance  to  DM-TS-B  must  support  the  LocaLTime,  LocaLDate, 
UTC_Offset,  and  Daylight_Savings_Status  properties  of  the  Device  object. 


A.5.15  BIBB  - Device  Management  • ReinitiahzeDevice  - A (DM-RD-A) ) 
The  A device  is  authorized  to  reinitialize  the  B device. 


BACnet  Service 

Initiate 

Execute 

ReinitializeDevice 

X 

Devices  claiming  conformance  to  DM-RD-A  shall  be  able  to  initiate  ReinitializeDevice  requests 
containing  the  Password  parameter.  This  shall  be  both  for  warm  and  cold  start. 
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A.5.16  BIBB  ■ Device  Management  - ReinitializeDevice  - B (DM-RD-B) 

The  B device  performs  reinitialization  requests  from  the  A device.  The  optional  password  field 
shall  be  supported. 


BACnet  Service 

Initiate 

Execute 

ReinitializeDevice 

X 

A.5.17  BIBB  - Device  Management  - Backup  and  Restore  - A (DM-BR-A) 

The  A device  uploads  a file  which  contains  the  configuration  of  the  B device  and  downloads  that 
file  to  the  B device  should  it  need  to  be  restored  to  its  previously  backed-up  state. 


BACnet  Service 

Initiate 

Execute 

AtomicReadFile 

X 

AtomicWriteFile 

X 

Devices  claiming  conformance  to  DM-BR-A  must  write  the  value  TRUE  to  the  Archive  property 
of  the  File  object  which  represents  the  configuration  file  in  the  B device  following  a backup 
operation.  Configuration  file  uploads  and  downloads  shall  be  performed  using  stream-oriented 
file  access. 


A.5.18  BIBB  - Device  Management  - Backup  and  Restore  - B (DM-BR-B) ) 

The  B device  provides  its  configuration  file  to  the  A device  and  allows  the  A device  to  download 
this  file  to  recover  its  configuration  in  the  event  of  a failure. 


BACnet  Service 

Initiate 

Execute 

AtomicReadFile 

X 

AtomicWriteFile 

X 

In  devices  claiming  conformance  to  DM-BR-B,  the  Read_Only  property  of  File  objects  which 
represent  configuration  files  shall  contain  the  value  FALSE,  the  File_Type  property  shall  contain 
the  value  CONFIGURATION,  and  the  File_Size  property  shall  be  writable.  Configuration  file 
uploads  and  downloads  shall  be  performed  using  stream-oriented  file  access. 


A.5.19  BIBB  - Device  Management  - List  Manipulation  - A (DM-LM-A) 

Many  BACnet  object  types  have  properties  that  are  lists  of  a particular  datatype.  The  A device 
can  add  and  remove  list  elements  in  properties  of  objects  in  the  B device. 


BACnet  Service 

Initiate 

Execute 

AddListElement 

X 

RemoveListElement 

X 
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A. 5.20  BIBB  - Device  Management  - List  Manipulation  > B (DM-LM-B) 
The  B device  responds  to  requests  to  add  or  remove  list  elements. 


BACnet  Service 

Initiate 

Execute 

AddListElement 

X 

RemoveListElement 

X 

A. 5.21  BIBB  - Device  Management  - Object  Creation  and  Deletion  - A (DM-OCD-A) 

BACnet  allows  object  instances  to  be  dynamically  created  and  deleted.  The  A device  may 
dynamically  create  and  delete  the  object  types  supported  by  the  B device. 


BACnet  Service 

Initiate 

Execute 

CreateObject 

X 

DeleteObiect 

X 

A.5.22  BIBB  - Device  Management  - Object  Creation  and  Deletion  - B (DM-OCD-B) 

The  B device  creates  and  deletes  object  instances  based  on  requests  from  the  A device.  The 
object  types  whose  dynamic  creation  and  deletion  is  supported  shall  be  enumerated  in  the  B 
device's  PICS. 


BACnet  Service 

Initiate 

Execute 

CreateObject 

X 

DeleteObiect 

X 

A.6  Network  Management  BIBBs 

These  BIBBs  prescribe  the  BACnet  capabilities  required  to  interoperably  perform  the  network 
management  functions  enumerated  in  3.5  for  the  BACnet  devices  defined  therein. 

A.6.1  BIBB  - Network  Management  - Connection  Establishment  - A (NM-CE-A) 

The  A device  commands  a half-router  to  establish  and  terminate  connections  as  needed  for 
communication  with  other  devices. 


BACnet  Network  Layer  Message 

Initiate 

Execute 

Establish-Connection-To-Network 

X 

Disconnect-Connection-To-Network 

X 
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A.6.2  BIBB  - Network  Management  - Connection  Establishment  - B (NM-CE-B) 

The  B device  executes  commands  to  establish  and  terminate  connections  as  needed. 


BACnet  Network  Layer  Message 

Initiate 

Execute 

Establish-Connection-To-Network 

X 

Disconnect-Connection-To-Network 

X 

A.6.3  BIBB  - Network  Management  - Router  Configuration  - A (NM-RC-A) 

The  A device  may  query  and  change  the  configuration  of  routers  and  half-routers.  Note  that  the 
capabilities  of  routers  and  half-routers  are  defined  in  BACnet  Clause  6.  Thus  no  explicit  BIBBs 
are  required. 


BACnet  Network  Layer  Message 

Initiate 

Execute 

Who-Is-Router-To-Network 

X 

I-Am-Router-To-Network 

X 

I-Could-Be-Router-To-Network 

X 

Initialize-Routing-Table 

X 

Initialize-Routing-Table-Ack 

X 

A.7  Virtual  Terminal  BIBBs 

Virtual  terminal  services  permit  "remote  console"  access  of  field  devices  from  across  a BACnet 
LAN.  The  effect  is  to  enable  access  to  proprietary  configuration  and  diagnostic  routines  from  a 
workstation  as  if  the  workstation  were  directly  connected  to  the  field  device  in  the  mechanical 
room. 


A.7.1  BIBB  - Virtual  Terminal  - A (VT-A) 

The  A device  initiates  a virtual  terminal  session  and  exchanges  data  with  the  B device. 


BACnet  Service 

Initiate 

Execute 

VT-Open 

X 

VT-Close 

X 

X 

VT-Data 

X 

X 
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A.7.2  BIBB  - Virtual  Terminal  - B (VT-B) ) 


The  B devices  permits  the  establishment  of  a virtual  terminal  session  and  exchanges  data  with 
the  A device. 


BACnet  Service 

Initiate 

Execute 

VT-Open 

x 

VT-Close 

X 

X 

VT-Data 

X 

X 
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Annex  B.  Descriptions  and  Profiles  of  Standardized  BACnet  Devices 

This  clause  provides  descriptions  of  five  "standardized"  types  of  BACnet  devices.  Any  device 
that  implements  all  the  required  BACnet  capabilities  for  a particular  device  type  and 
interoperability  area  may  claim  to  be  a device  of  that  particular  type.  Devices  may  also  provide 
additional  capabilities  and  shall  indicate  these  capabilities  in  their  PICS.  The  devices  defined 
herein  are:  BACnet  Operator  Workstation,  BACnet  Building  Controller,  BACnet  Advanced 
Application  Controller,  BACnet  Application  Specific  Controller,  BACnet  Smart  Actuator,  and 
BACnet  Smart  Sensor. 

B.l  BACnet  Operator  Workstation  (B-OWS) 

The  B-OWS  is  the  operator's  window  into  a BACnet  system.  While  it  is  primarily  used  for  the 
operation  of  a system,  it  may  be  used  for  configuration  activities  that  are  beyond  the  scope  of  this 
standard.  It  is  not  intended  to  perform  direct  digital  control  It  enables  the  specification  of  the 
following: 

Data  Sharing 

• Archival  storage  of  data 

• Presentation  of  data  (Le.,  reports  and  graphics) 

• The  ability  to  monitor  the  value  of  all  BACnet  object  types,  including  all  required  and 
optional  properties 

• The  ability  to  modify  setpoints  and  parameters 
Alarm  and  Event  Management 

• Operator  notification  and  presentation  of  event  information 

• Alarm  acknowledgment  by  operators 

• Alarm  summarization 

• Adjustment  of  alarm  limits 

• Adjustment  of  alarm  routing 

Scheduling 

• Modification  of  schedules 

• Display  of  the  start  and  stop  times  (schedule)  of  scheduled  devices 
Trending 

• Modification  of  the  parameters  of  a trend  log 

• Display  and  archive  of  trend  data 


56 


Device  and  Network  Management 

• Display  of  information  about  the  status  of  any  device  on  the  BACnet  inter-network 

• Display  of  information  about  any  object  in  the  BACnet  inter-network 

• Ability  to  silence  a device  on  the  network  that  is  transmitting  erroneous  data 

• Ability  to  synchronize  the  time  in  devices  across  the  BACnet  inter-network 

• Ability  to  cause  a remote  device  to  reinitialize  itself 

• Ability  to  backup  and  restore  the  configuration  of  other  devices 

• Ability  to  command  half-routers  to  establish  and  terminate  connections 

• Ability  to  query  and  change  the  configuration  of  half-routers  and  routers 

B.2  BACnet  Building  Controller  (B-BC) 

A B-BC  is  a general  purpose,  field  programmable  device  capable  of  carrying  out  a variety  of 
building  automation  and  control  tasks.  It  enables  the  specification  of  the  following: 

Data  Sharing 

• Ability  to  provide  the  values  of  any  of  its  BACnet  objects 

• Ability  to  retrieve  the  values  of  BACnet  objects  from  other  devices 

• Ability  to  allow  modification  of  some  or  all  of  its  BACnet  objects  by  another  device 

Alarm  and  Event  Management 

• Generation  of  alarm  / event  notifications  and  the  ability  to  direct  them  to  recipients 

• Maintain  a list  of  unacknowledged  alarms  / events 

• Notifying  other  recipients  that  the  acknowledgment  has  been  received 

• Adjustment  of  alarm  / event  parameters 

Scheduling 

• Ability  to  schedule  output  actions,  both  in  the  local  device  and  in  other  devices,  both  binary 
and  analog,  based  on  date  and  time 

Trending 

• Collection  and  delivery  of  (time,  value)  pairs. 

Device  and  Network  Management 

• Ability  to  respond  to  information  about  its  status 

• Ability  to  respond  to  requests  for  information  about  any  of  its  objects 

• Ability  to  respond  to  communication  control  messages 

• Ability  to  synchronize  its  internal  clock  upon  request 

• Ability  to  perform  re-initialization  upon  request 

• Ability  to  upload  its  configuration  and  allow  it  to  be  subsequently  restored 

• Ability  to  command  half-routers  to  establish  and  terminate  connections 
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B.3  BACnet  Advanced  Application  Controller  (B-AAC) 

A B-AAC  is  a control  device  with  limited  resources  relative  to  a B-BC.  It  may  be  intended  for 
specific  applications  and  supports  some  degree  of  programmability. 

Data  Sharing: 

• Ability  to  provide  values  for  any  of  its  BACnet  objects  upon  request 

• Ability  to  allow  modification  of  some  or  all  of  its  BACnet  objects  by  another  BACnet  device 

Alarm  and  Event  Management 

• Generation  of  limited  alarm  and  event  notifications  and  the  ability  to  direct  them  to  recipients 

• Tracking  acknowledgements  of  alarms  from  human  operators 

• Adjustment  of  alarm  parameters 

Scheduling 

• Ability  to  schedule  actions  in  the  local  device  based  on  date  and  time 

Trending 

• No  requirement 

Device  and  Network  Management 

• Ability  to  respond  to  queries  about  its  status 

• Ability  to  respond  to  requests  for  information  about  any  of  its  objects 

• Ability  to  respond  to  communication  control  messages 

• Ability  to  synchronize  its  internal  clock  upon  request 

• Ability  to  perform  re-initialization  upon  request 

B.4  BACnet  Application  Specific  Controller  (B-ASC) 

A B-ASC  is  a controller  with  limited  resources  relative  to  a B-AAC.  It  is  intended  for  use  in  a 
specific  application  and  supports  limited  programmability.  It  enables  specification  of  the 
following: 

Data  Sharing 

• Ability  to  provide  the  values  of  any  of  its  BACnet  objects 

• Ability  to  allow  modification  of  some  or  all  of  its  BACnet  objects  by  another  device 

Alarm  and  Event  Management 

• None 

Scheduling 

• None 

Trending 

• None 
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Device  and  Network  Management 

• Ability  to  respond  to  information  about  its  status 

B.5  BACnet  Smart  Actuator  (B-SA) 

A B-SA  is  a simple  control  device  with  limited  resources,  intended  for  specific  applications. 
Data  Sharing: 

• Ability  to  provide  values  for  any  of  its  BACnet  objects  upon  request 

• Ability  to  allow  modification  of  some  or  all  of  its  BACnet  objects  by  another  device 

Alarm  and  Event  Management 

• No  requirement 

Scheduling 

• No  requirement 

Trending 

• No  requirement 

Device  and  Network  Management 

• No  requirement 

B.6  BACnet  Smart  Sensor  (B-SS) 

An  SS  is  a simple  sensing  device  with  very  limited  resources. 

Data  Sharing: 

• Ability  to  provide  values  for  any  of  its  BACnet  objects  upon  request 

Alarm  and  Event  Management 

• No  requirement 

Scheduling 

• No  requirement 

Trending 

• No  requirement 

Device  and  Network  Management 

• No  requirement 
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B.7  BACnet  Gateway  (B-GW) 


A B-GW  is  a device  that  provides  bi-directional  translation  of  data  and  information  between 
BACnet  devices  and  devices  that  communicate  using  a non-BACnet  communication  protocol  It 
enables  specification  of  the  following: 

Data  Sharing: 

• Ability  to  provide  values  for  any  point  on  the  non-BACnet  side  of  the  gateway  to  BACnet 
devices  as  if  the  values  were  originating  from  BACnet  objects 

• Ability  to  allow  BACnet  devices  to  modify  some  or  all  of  the  point  values  on  the  non-BACnet 
side  of  the  gateway  by  using  standard  BACnet  write  services 

Alarm  and  Event  Management 

• Generation  of  alarm  / event  notifications  and  the  ability  to  direct  them  to  recipients 

• Maintenance  of  a list  of  unacknowledged  alarms  / events 

• Notification  of  other  recipients  that  an  acknowledgment  has  been  received 

• Adjustment  of  alarm  / event  parameters 

Scheduling 

• Ability  to  schedule  output  actions,  both  in  the  local  device  and  in  other  devices,  both  binary 
and  analog,  based  on  date  and  time 

Trending 

• Collection  and  delivery  of  (time,  value)  pairs 

Device  and  Network  Management 

• Ability  to  respond  to  information  about  its  status 

• Ability  to  respond  to  requests  for  information  about  any  of  its  objects 

• Ability  to  respond  to  communication  control  messages 

• Ability  to  synchronize  its  internal  clock  upon  request 

• Ability  to  perform  re-initialization  upon  request 
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B.8  Profiles  of  the  Standard  BACnet  Devices 

The  following  tables  indicate  which  BIBBs  must  be  supported  by  each  device  type  for  each 
interoperability  area. 


B-OWS 

B-BC 

B-AAC 

B-ASC 

B-SA 

B-SS 

B-GW 

Data  Sharing 

DS-RP-A.B 

DS-RP-A,B 

DS-RP-B 

DS-RP-B 

DS-RP-B 

DS-RP-B 

DS-RP-B 

DS-RPM-A 

DS-RPM-A.B 

DS-RPM-B 

DS-WP-B 

DS-WP-B 

DS-RPM-B 

DS-WP-A 

DS-WP-A.B 

DS-WP-B 

DS-WP-B 

DS-WFM-A 

DS-WPM-B 

DS-WPM-B 

DS-WPM-B 

DS-COVU-AB 

B-OWS 

B-BC 

B-AAC 

B-ASC 

B-SA 

B-SS 

B-GW 

Alarm  & Event 

AE-N-A 

AE-N-B 

AE-N-B 

AE-N-B 

Memt 

AE-ACK-A 

AE-ACK-B 

AE-ACK-B 

AE-ACK-B 

AE-ASUM-A 

A-ASUM-B 

AE-ASUM-B 

A-ASUM-B 

AE-ESUM-A 

AE-ESUM-B 

AE-ESUM-B 

B-OWS 

B-BC 

B-AAC 

B-ASC 

B-SA 

B-SS 

B-GW 

Scheduling 

SCHED-A 

SCHED-B 

SCHED-B 

SCHED-B 

B-OWS 

B-BC 

B-AAC 

B-ASC 

B-SA 

B-SS 

B-GW 

Trending 

T-VMT-A  * 

T-VMT-B  * 

T-VMT-B* 

T-ATR-A* 

T-ATR-B* 

T-ATR-B* 

B-OWS 

B-BC 

B-AAC 

B-ASC 

B-SA 

B-SS 

B-GW 

Device  & 

DM-DDB-A.B 

DM-DDB-A.B 

DM-DDB-B 

DM-DDB-B 

DM-DDB-B 

Network  Memt 

DM-DOB-A.B 

DM-DOB-A.B 

DM-DOB-B 

DM-DOB-B 

DM-DOB-B 

DM-DCC-A 

DM-DCC-B 

DM-DCC-B 

DM-DCC-B 

DM-DCC-B 

DM-TS-A 

DM-TS-B 

OT 

DM-UTC-B’ 

DM-TS-B 

or 

DM-UTC-B* 

DM-TS-B 

or 

DM-UTC-B* 

DM-UTC-A* 

DM-RD-A 

DM-RD-B 

DM-RD-B 

DM-RD-B 

DM-BR-A 

DM-BR-B 

NM-CE-A 

NM-CE-A 

* At  the  time  of  publication  of  this  guide  the  BACnet  services  required  to  implement  these  BIBBs  have  not 
completed  the  public  review  process  for  becoming  part  of  the  BACnet  standard. 
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Annex  C.  GSA  BACnet  Implementation  Checklist 

The  purpose  of  this  Annex  is  to  provide  a simple  checklist  to  ensure  that  the  most  important 
elements  of  a successful  BACnet  building  automation  and  control  system  have  been  considered 
and  specified  as  needed. 

General 

□ Have  the  functional  requirements  of  the  job,  including  all  sequences  of  operation,  been 
thoroughly  specified? 

□ Have  all  the  desired  workstation  capabilities,  features,  and  characteristics  been  specified 
including: 

□ Graphics 

□ Tabular  reports 

□ Trend  logs 

□ Operator  tools 

□ Security  levels  and  privileges 

□ Have  the  desired  local  or  wide  area  network  technologies  been  specified?  If  communication 
via  an  IP  internet  is  required,  has  the  use  of  BACnet  Tunneling  Routers  or  BACnet/IP  been 
specified? 

□ Has  BACnet  been  specified  for  all  levels  of  the  control  system  hierarchy  using  devices 
conforming  to  the  profiles  in  Annex  B? 

Data  Sharing  (3.1) 

PomUisl 

□ Have  point  lists  been  compiled  showing  each  sensor,  actuator,  setpoint,  and  other  parameters 
that  are  to  be  accessible  over  the  network? 

Presentation  of  data 

□ Has  the  format  and  desired  content  of  each  tabular  report  been  specified? 

□ Have  the  desired  graphic  displays  been  defined  along  with  the  maximum  allowable  update 
interval? 

□ Has  it  been  specified  that  all  points  in  the  system  must  be  available  for  real-time  plotting  at 
user-definable  update  intervals  and  that  multiple  analog  and  binary  values  may  be  plotted  on 
the  same  axes? 
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Monitoring  of.  any. property.  of, any.BACret.  Qbjggt  type 


□ Has  it  been  specified  that  it  must  be  possible  to  read  and  display  the  value  of  any  property  of 
any  object  in  the  system? 

Global -Q.bjeg^ 

□ Have  all  shared  global  data  points  been  specified? 

Setpoint  and  parameter  modification 

□ Has  it  been  specified  which  operating  setpoints  and  parameters  must  be  available  for 
modification  via  BACnet  services  (as  opposed  to  proprietary  vendor-specific  means)? 

□ Have  the  desired  means  of  making  the  modifications,  e.g.,  via  a graphical  user  interface 
(GUI),  been  specified? 

Peer-to-Peer  data  exchange 

□ Have  any  required  data  dependencies  (interlocks,  shared  setpoints,  schedules,  and  so  on)  that 
must  be  implemented  via  the  network  been  defined? 

Alarm  and  Event  Management  (3.2) 

Alarm  lists,  operator  notification  and  presentation  of  event  information 

□ Have  all  desired  alarms,  including  alarm  limits,  interlocks  to  avoid  "nuisance"  alarms,  and 
desired  response  time  from  the  occurrence  of  an  event  until  a notification  is  provided  been 
specified? 

□ Has  it  been  specified  how  alarms  are  to  be  categorized  and  distributed,  Le.,  which  alarms  go 
where  and  when? 

□ Has  it  been  specified  how  alarms  are  to  appear  at  the  operator  workstation? 

□ Has  it  been  specified  that  "intrinsic  reporting"  shall  be  used  when  it  is  sufficient  to  meet  the 
functional  requirements? 

Alarm  acknowledgment 

□ Has  it  been  specified  that  alarm  acknowledgment  capability  be  provided  and  that  a log  be 
maintained  that  records  when  an  alarm  notification  was  received,  when  it  was  acknowledged, 
and  by  whom? 
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Alarm  summarization 


□ Has  it  been  specified  that  it  shall  be  possible  for  an  operator  to  receive,  at  any  time,  a 
summary  of  all  alarms  that  are  currently  in  effect  and  whether  or  not  they  have  been 
acknowledged? 

□ Has  it  been  specified  that  is  shall  be  possible  to  receive  a summary  of  all  alarms  regardless  of 
acknowledgment  status;  for  which  a particular  recipient  is  enrolled  for  notification;  based  on 
current  event  state;  based  on  the  particular  BACnet  event  algorithm  (e.g.,  change  of  value, 
change  of  state,  out  of  range,  and  so  on);  alarm  priority;  and  notification  class? 

Alarm  parameter  adjustment 

□ Has  it  been  specified  that  operators  shall  be  provided  the  capability  to  dynamically  modify 
the  alarm  parameters  for  all  standard  BACnet  event  types? 

Alarm  routing  adjustment 

□ Has  it  been  specified  that  operators  shall  have  the  ability  to  change  alarm  routing  for  each 
alarm  including  the  destination  for  each  type  of  alarm  and  alarm  priority,  the  day  of  week 
and  time  of  day,  and  the  type  of  transition  involved  (TO-OFFNORMAL,  TO-NORMAL  and 
so  on)? 

Scheduling  (3  J) 

Schedule  list 

□ Has  each  action  that  should  take  place  based  on  the  date  and  time  of  day  been  specified? 

Display  of  start  and  stop  times  of  scheduled  devices 

□ Has  it  been  specified  that  an  operator  shall  be  able  to  inspect  the  content  of  any  schedule  and 
determine  the  specific  control  actions  that  will  occur  at  any  time,  on  any  date?  Additionally, 
for  any  particular  device  or  system  parameter  that  is  the  subject  of  a schedule,  has  it  been 
specified  that  an  operator  shall  be  able  to  determine  the  schedule  of  actions  related  to  that 
device  or  parameter? 

Modification  of  schedules 

□ Has  it  been  specified  that  certain,  or  all,  calendar  entries  and  schedules  shall  be  modifiable 
from  an  operator  workstation? 

Trending  (3.4) 

Archival  storage  of  data 

□ Has  the  maximum  number  of  data  points  for  which  archival  storage  is  needed,  along  with  the 
minimum  sampling  interval  been  specified? 
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□ Has  the  duration  of  time  for  which  the  archived  information  must  be  available  for  on-line 
retrieval  been  specified? 

□ Has  the  means  for  archiving  older  data,  e.g.,  tape  or  CD-R,  been  specified? 

Trend  list 

□ Have  the  initial  requirements  for  trending  in  terms  of  which  data  points  are  to  be  trended,  the 
sampling  rate,  the  duration  of  each  trend  log,  and  the  length  of  time  it  is  desired  to  keep  the 
resulting  logs  available  on-line  been  specified?  Alternatively,  have  the  approximate  number 
of  desired  trend  logs  been  specified? 

Display  and  archive  of  trend  data 

□ Has  it  been  specified  that  an  operator  will  be  able  to  retrieve  and  display  trend  logs,  access 
the  underlying  numerical  data  in  spreadsheet  format,  and  output  the  data  to  printers  or  other 
files? 

Modification  of  trend  log  parameters 

□ Has  it  been  specified  that  the  data  points  to  be  logged,  the  sampling  rate,  and  duration  of 
trend  logs  shall  be  modifiable  by  an  authorized  operator  from  a system  workstation? 

Device  and  Network  Management  (3.5) 

Display  of  information  about  device  status 

□ Has  it  been  specified  that  an  operator  shall  be  able  to  display  at  any  time  the  operational 
status  of  any  device  on  the  BACnet  internetwork? 

Display  of  information  about  anv  BACnet  object 

□ Has  it  been  specified  that  an  operator  shall  be  able  to  display  at  any  time  any  property  of  any 
BACnet  object? 

□ Has  it  been  specified  that  an  operator  shall  also  be  able  to  display  property  values  of  objects 
grouped  by  object  type,  object  location,  and  building  system? 

Ability  to  silence  a device  on  the  network  that  is  transmitting  erroneous  data 

□ Has  it  been  specified  that  an  operator  shall  be  able  to  direct  a field  device  to  stop  transmitting 
event  or  alarm  notifications  until  a subsequent  command  to  resume  transmissions  is 
received? 
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Ability  to  synchronize  the  time  in  devices  across  the  BACnet  inter-network 


□ Has  it  been  specified  that  an  operator  shall  be  able  to  set  the  time  and  date  in  any  device  on 
the  network  that  supports  time-of-day  functionality?  This  capability  should  be  required  for 
both  individual  devices  or  groups  of  devices,  including  all  devices  simultaneously. 

Ability  to  cause  a remote  device  to  reinitialize  itself 

□ Has  it  been  specified  that  an  operator  shall  have  the  ability  to  issue  reinitialization  commands 
to  any  device  that  supports  remote  reinitialization? 

Ability  to  backup  and  restore  the  configuration  of  other  devices 

□ Has  it  been  specified  that  an  operator  shall  have  the  ability  to  backup  and  restore  all  BACnet 
devices  on  the  network  that  support  this  capability? 

Ability  to  command  half-routers  to  establish  and  terminate  connections 

□ Has  it  been  specified  that  an  operator  shall  have  the  ability  to  issue  a command  for  the 
establishment  or  termination  of  a connection  to  a remote  BACnet  network? 

Ability  to  query  and  change  the  configuration  of  half-routers  and  routers 

□ Has  it  been  specified  that  an  operator  shall  have  the  ability  to  display  and  modify  the  routing 
table  entries  in  all  provided  BACnet  half-routers  and  routers? 

Use  of  BACnet  Objects  (4) 

Naming  Conventions  (4.11 

□ Has  a set  of  abbreviations  for  common  building  systems,  subsystems,  and  points  that  are  to 
be  used  by  all  vendors  been  specified? 

□ Has  it  been  specified  that  object  name  properties,  in  those  devices  where  the  object  name  is 
configurable,  shall  be  at  least  50  characters  long  and  shall,  to  the  extent  possible  make  use  of 
a system  and  point  nomenclature  using  the  abbreviations  specified  above? 

□ Has  it  been  specified  that  BACnet  object  names  used  in  workstations  may  be  up  to  50 
characters  long  and  shall  consist  of  a string  made  up  of  components  indicating,  as 
appropriate,  the  location,  system,  subsystem,  and  point  of  the  object?  Also,  that  these  object 
names  shall  be  used  in  workstation  applications  such  as  graphics,  reports,  and  alarms 
wherever  an  object  name  is  appropriate  in  lieu  of  the  object  name  property  in  the  remote 
device?  Also,  that  an  operator  may  display  at  any  time  the  mapping  between  the  object  name 
used  on  the  workstation  and  the  object  name  property  used  in  the  remote  BACnet  device? 
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Q?.mj^.siQiungJ)iagnQsJic  Mq4s  (4t2) 


□ Has  it  been  specified  that  the  Out_Of_Service  property  shall  be  adjustable  (writable)  using 
BACnet  services  for  all  Analog,  Binary,  Multi-state,  Loop  and  Program  objects? 

Using  Pbi^LD.e.scriptions_(4.1) 

□ Has  it  been  specified  that  each  Device  object  shall  have  a Description  property  and  that  the 
length  available  for  the  Description  properties  of  other  implemented  object  types  shall  be 
provided  in  the  "Property  Range  Restrictions"  portion  of  the  device’s  PICS? 

Issues  Related  to  Specific  BACnet  Object  Types  (4.4) 

Analog  Input,  Output,  and  Value  (4,4.1) 

□ Has  it  been  specified  that  all  analog  objects  (Input,  Output,  and  Value)  shall  have  the 
capability  of  using  the  Change  of  Value  reporting  mechanism  and  that  the  COVJncrement 
property  shall  be  writable  using  BACnet  services? 

Bjnary_Input_(4A2^ 

□ Has  it  been  specified,  for  each  Binary  Input  object,  the  text  to  be  used  for  the  InactiveJText 
and  Active_Text  properties? 

Binary  Output  (4,4.3) 

□ Has  it  been  specified,  for  each  Binary  Input  object,  the  text  to  be  used  for  the  InactiveJText 
and  Active_Text  properties?  In  addition,  if  appropriate  for  the  application,  have  appropriate 
values  for  the  Feedback.. Value,  Minimu m.„On,,Time , and  Minimum,.Off _T ime  properties 
been  specified? 

O Has  support  for  the  Change„Of_StateJTime,  Change„Of„State„Coimt,  and 
Time_Of_State_Count_Reset  been  specified  if  counting  state  changes  is  appropriate  for  the 
application?  If  so,  has  it  also  been  specified  that  Change_Of„State„Count  be  writable  so  that 
the  count  can  be  reset? 

□ Has  support  for  the  Elapsed^ Active JTime  and  Time„OLActiveJTimeJReset  properties  been 
specified  if  accumulating  run  time  is  appropriate  for  the  application?  If  so,  has  it  also  been 
specified  that  Elapsed„Active_Time  be  writable  so  that  the  run  time  can  be  reset? 

Binary  Value  (4.4.41 

□ Has  it  been  specified,  for  each  Binary  Value  object,  the  text  to  be  used  for  the  InactiveJText 
and  Active JText  properties?  In  addition,  if  appropriate  for  the  application,  have  appropriate 
values  for  the  Minimu m„On_Time,  and  Minimum_OfLTime  properties  been  specified? 
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□ Has  support  for  the  Change_Of_State„Time,  Change_Of_State_Count,  and 
Time_Of_State_Count_Reset  been  specified  if  counting  state  changes  is  appropriate  for  the 
application?  If  so,  has  it  also  been  specified  that  Change_Of_State_Count  be  writable  so  that 
the  count  can  be  reset? 

□ Has  support  for  the  Elapsed_Active_Time  and  Time_Of_Active_Time_Reset  properties  been 
specified  if  accumulating  run  time  is  appropriate  for  the  application?  If  so,  has  it  also  been 
specified  that  Elapsed_Active_Time  be  writable  so  that  the  run  time  can  be  reset? 

Calendar  (4,4.5) 

□ Has  it  been  specified  that  devices  that  provide  scheduling  capability  shall  also  provide  at 
least  one  Calendar  object  with  a capacity  of  at  least  10  entries  and  that  it  shall  be  possible  to 
view  the  Calendar  object  and  make  modifications  from  any  BACnet  workstation  on  the 
network? 

□ Has  it  been  specified,  if  the  Calendar's  Date_List  property  is  writable  using  BACnet  services, 
that  all  calendar  entry  datatypes  must  be  supported? 

Loop  (4.4.61 

□ Has  it  been  specified  that  the  desired  PID  control  loops  shall  be  represented  by  Loop  objects 
and  that  the  tuning  constant  properties  shall  be  writable?  Has  writability  of  other  Loop 
properties  been  specified  as  appropriate  to  the  application? 

□ Has  it  been  specified  that  all  Loop  objects  shall  have  the  capability  of  using  the  Change  of 
Value  reporting  mechanism  and  that  the  COV_Increment  property  shall  be  writable  using 
BACnet  services? 

Multi-state  Input.  Output,  and  Value  (4.4.7) 

□ Has  it  been  specified,  for  each  Multi-state  Input,  Output,  and  Value  object,  the  text  to  be  used 
for  each  state  that  the  object  can  represent?  In  addition,  if  appropriate  for  the  application,  has 
it  also  been  specified  how  the  Feedback_ Value  is  to  be  determined? 

□ Has  it  been  specified  that  all  Multi-state  Input,  Output,  and  Value  objects  shall  have  the 
capability  of  using  the  Change  of  Value  reporting  mechanism  and  that  the  COV_Increment 
property  shall  be  writable  using  BACnet  services? 

Schedule  (4.4.8) 

□ Has  each  building  system  that  is  to  be  subjected  to  date  and  time  scheduling  been  specified 
and  that  it  shall  be  possible  to  modify  schedule  entries  from  a BACnet  workstation? 

Dynamic  Object  Creation  (4.5) 

□ Has  it  been  specified,  if  required  by  the  application,  that  it  shall  be  possible  to  dynamically 
create  instances  of  the  Averaging,  Calendar,  Event  Enrollment,  Group,  Notification  Class, 
Schedule,  and  Trend  Log  objects? 
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Use  of  B ACnet  Services  (5) 

Interoperable  Commands  (5. 1) 

□ Have  the  processes  that  are  to  be  prioritized  and  the  command  priority  levels  assigned  to 
each  if  they  do  not  fall  into  the  pre-assigned  levels  shown  in  Table  1 been  specified?  For 
each  point  subject  to  the  command  priority  scheme,  has  a default  status,  position,  or  value  for 
the  point  to  take  on  in  the  absence  of  a prioritized  command  been  specified? 

Assigning  Alarm  Priorities  (5,2,1) 

□ Have  the  priority  values  to  be  assigned  for  each  alarm  in  the  system  been  specified?  For  each 
priority  value,  or  range  of  values,  have  the  actions  to  be  taken  upon  receipt  been  specified? 

getting  up  Notification  Classes  (g.2t2) 

□ Has  it  been  specified  how  alarms  should  be  distributed  by  specifying  the  recipients  of  each 
type  and  priority  of  alarm?  If  desired,  have  the  valid  days  of  the  week  and  times  of  the  day 
for  each  been  specified? 

Event  Notification  Message  Texts  (5.23) 

□ Have  the  content  and  format  of  the  alarm  messages  that  will  be  delivered  to  operators  been 
specified? 

Assigning  Levels  of  Authority  to  Certain  Operators  15^3) 

□ Has  it  been  specified,  if  desired,  the  number  of  authorization  levels  and  the  operator  accounts 
to  be  assigned  to  each?  If  password  protection  for  remote  device  management  services  is 
needed,  have  the  passwords  to  be  configured  been  specified?  Alternatively,  has  it  been 
specified  that  there  shall  be  a method  provided  for  dynamically  assigning  passwords  for 
remote  device  management  functions  after  installation? 

Subscribed  COY  Notifications  (5.4,11 

□ Has  it  been  specified  that  workstation  software  shall  be  provided  that  has  the  capability  of 
subscribing  to  COV  notifications  for  all  object  types  that  support  it? 

Unsubscribed  COV  Notifications  (5.4.21 

□ Has  it  been  specified  that  changes  of  value  of  globally  shared  data  shall  be  distributed  by 
means  of  UnconfirmedCOVNotifications? 

Time  Synchronization  (5.51 

□ Has  it  been  specified  that  a time  master  shall  be  provided  along  with  the  format  of  the  time 
synchronization  messages,  either  local  time  or  UTC? 
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Specifying  System/Network  Architecture  (6) 

System  Architectures  (6.1) 


□ Has  it  been  specified  that  BACnet  shall  be  used  throughout  the  building  automation  and 
control  internetwork  at  all  levels,  Le.,  that  the  system  shall  be  "native"  BACnet? 

□ Has  it  been  specified  that  the  internetwork  shall  be  configured  such  that,  if  three  or  more 
networks  are  involved  with  different  performance  characteristics,  the  faster  networks  shall  be 
used  to  interconnect  the  slower  ones? 

Local  Area  Network  Selection  (6.2) 

ISO  8802-3,  Ethernet  (6.2.1) 

□ Has  it  been  specified  which  devices  in  the  control  system  should  reside  on  the  Ethernet 
LAN? 

□ Has  the  transmission  medium  option  that  is  to  be  used  been  specified?  If  more  than  one  will 

be  used,  has  it  been  specified  which  one  is  to  be  used  where,  and  the  devices  that  are  to  be 

connected?  If  hubs  will  be  needed,  have  the  number  of  ports  and  the  kind  of  medium  for  each 
port  been  specified? 

□ Has  the  Ethernet  speed  (10  Mbps  or  100  Mbps)  been  specified? 

ANSI/ATA  878.1.  ARCNET  (6.2.2) 

□ Has  it  been  specified  which  devices  in  the  control  system  should  reside  on  the  ARCNET 
LAN? 

□ Has  the  transmission  medium  option  that  is  to  be  used  been  specified?  If  more  than  one  will 

be  used,  has  it  been  specified  which  one  is  to  be  used  where  and  the  devices  that  are  to  be 

connected?  If  hubs  will  be  needed,  have  the  number  of  ports  and  the  kind  of  medium  for  each 
port  been  specified? 

□ Has  it  been  specified  how  ARCNET  addresses  are  to  be  assigned? 

Master-Slave/Token-Passing.  MS/TP  (6.2.3) 

□ Has  it  been  specified  which  devices  in  the  control  system  should  reside  on  the  MS/TP  LAN? 

□ Has  the  baud  rate  to  be  used  been  specified? 

□ Has  it  been  specified  how  MS/TP  addresses  are  to  be  assigned  and,  if  slave  devices  will  be 
used,  how  the  address  space  is  to  be  divided  between  slaves  and  masters? 
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EIA-709.1.  LonTalk  (6.2.4) 


□ Has  it  been  specified  which  devices  in  the  control  system  should  reside  on  the  LonTalk 
LAN? 

□ Have  the  media,  speed  and  topology  to  be  used  been  specified? 

□ Has  it  been  specified  how  LonTalk  addresses  are  to  be  assigned? 

Point-to-Point,  PTP  (6,2,5) 

□ Has  it  been  specified  that  PTP  shall  be  used  as  the  means  to  attach  to  a BACnet  LAN  via  a 
dial-up  connection  and  that  the  optional  password  protection  shall  be  provided? 

Specifying  MAC  Addresses  in  a Consistent  Manner  (6.3) 

□ Has  the  GSA,  the  design  engineer,  or  the  system  integrator  determined  how  MAC  addresses 
are  to  be  assigned  for  each  network  in  the  proposed  BACnet  internetwork  using  the 
recommendations  in  6.3? 

Network  Numbering  Conventions  (6.4) 

□ Has  the  GSA,  the  design  engineer,  or  the  system  integrator  determined  how  network  numbers 
are  to  be  assigned  for  each  network  in  the  proposed  BACnet  internetwork  using  the 
recommendations  in  6.4? 

Device  Object  Identifier  Conventions  (6.5) 

□ Has  the  GSA,  the  design  engineer,  or  the  system  integrator  determined  how  device  object 
identifiers  are  to  be  assigned  for  each  device  in  the  proposed  BACnet  internetwork  using  the 
recommendations  in  6.5? 

Use  of  BACnet  with  the  Internet  Protocols  (6.6) 

□ Has  it  been  specified,  if  existing  BACnet  non-IP  devices  are  to  be  interconnected  via  an  IP 
network,  that  BACnet  Tunneling  Routers  conforming  to  Annex  H shall  be  provided? 

□ Has  it  been  specified,  for  new  networks  which  need  IP  connectivity,  that  devices  shall  be 
provided  that  conform  to  Addendum  135a,  BACnet/IP  and  that,  for  broadcast  distribution, 
BBMDs  shall  be  provided  or  appropriate  arrangements  made  for  the  use  of  IP  multicasting? 

Routers  - Interconnecting  Multiple  BACnet  Networks  (6.7) 

□ Has  it  been  specified  that  it  shall  be  the  contractor's  responsibility  to  configure  each  router 
using  the  network  numbering  scheme  agreed  to  for  the  project? 

□ Has  it  been  specified  that  each  router  shall  be  configured  such  that  all  network  layer  error 
messages  shall  be  directed  to  a specific  workstation  using  the  BACnet 
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ConfirmedTextMessage  service?  Has  the  GSA,  the  design  engineer,  or  the  system  integrator 
determined  which  workstation  that  shall  be? 

□ Has  it  been  specified  that  it  shall  be  the  contractor's  responsibility  to  initially  configure  each 
router  with  routing  tables  containing  all  network  numbers  that  are  part  of  the  project’s 
internet? 

□ Has  it  been  specified  that  the  router  shall  be  able  to  receive  messages  at  each  port  of  any 
length  that  is  valid  for  the  LAN  technology  connected  to  that  port,  and  to  forward  the 
message  to  any  directly-connected  network  that  can  convey  a message  of  that  size? 

Message  Segmentation  (6.8) 

□ Has  it  been  specified  that  all  BACnet  devices  shall  support  the  reception  of  messages  up  to 
the  largest  size  permitted  by  the  LAN  technology  or  support  reception  of  segmented 
messages? 

□ Has  it  been  specified  that  all  BACnet  devices  shall  support  the  transmission  of  messages  up 
to  the  largest  size  permitted  by  the  LAN  technology  or  support  transmission  of  segmented 
messages? 

□ Has  it  been  specified  that  all  workstations  shall  support  both  segmented  message 
transmission  and  segmented  message  reception? 

□ Has  it  been  specified  that  all  BACnet  Building  Controllers  (see  B.2)  shall  support  both 
segmented  message  transmission  and  segmented  message  reception? 

Gateways  - Connecting  to  Legacy  Systems  (6.9) 

□ Has  it  been  specified  that  the  operator  workstation  shall  display  information  from  both  the 
BACnet  and  non-BACnet  devices?  If  appropriate,  has  it  been  specified  which  other  devices 
should  also  be  able  to  communicate  through  the  gateway? 

□ Has  it  been  specified  which  way  information  must  flow  through  the  gateway  or  that  the 
gateway  should  provide  bi-directional  communication? 

□ Has  it  been  specified  which  non-BACnet  points  are  to  be  readable  from  the  BACnet  side  of 
the  gateway  and  which  BACnet  objects  are  to  be  readable  from  the  non-BACnet  side  of  the 
gateway? 

□ Has  it  been  specified  which  non-BACnet  points  are  to  be  modifiable  from  the  BACnet  side 
of  the  gateway  and  which  BACnet  objects  are  to  be  modifiable  from  the  non-BACnet  side  of 
the  gateway? 

□ Has  it  been  specified  how  much  expansion  capacity  is  required  in  the  gateway? 

□ Has  it  been  specified  how  controller  program  and  configuration  database  archives  are  to  be 
created  and  maintained? 
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□ Have  any  gateway  features  that  will  be  needed  to  support  collection  of  trend  data  been 
specified? 

□ Have  any  gateway  features  that  will  be  needed  to  support  scheduling  been  specified? 

□ Have  any  gateway  features  that  will  be  needed  to  support  alarm  and  event  handling  been 
specified? 

Practical  Considerations  in  the  Construction  of  BACnet  Systems  (7) 

Pr^Uismen.t.Eha$g.,(7,l) 

If  an  RFP  is  to  used,  does  it  require  the  prospective  controls  vendor  to  provide  a description  of 
the  proposed  system  containing: 

□ Narrative  providing  an  overview  of  the  BAS  system,  primary  components,  workstation(s), 
and  LAN  architecture? 

□ Identification  of  any  clarifications  or  exceptions  to  the  project  specifications? 

□ A listing  and  quantification  of  all  microprocessor-based  BAS  equipment  to  be  supplied  and 
associated  information  “cut-sheets”  for  each? 

□ A listing  of  references,  as  appropriate,  for  projects  of  a similar  nature  to  the  proposed  BAS? 

□ The  option  of  requesting  a formal  BAS  demonstration  at  either  the  vendor’s  local  offices  or 
customer  location? 

Construction  Phase  (7,2) 

PICS  (7.2.1) 

Has  a PICS  been  provided  containing  at  least: 

□ BACnet  Standard  Application  Services  Supported? 

□ Standard  Object  Types  Supported? 

□ Data  Link  Layer  Options? 

□ Special  Functionality? 

□ Property  Range  Restrictions? 
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Points  Lists  (7.2.2) 

Have  Points  Lists  been  provided  containing  at  least: 

□ Hardware  I/O  information? 

□ Proposed  I/O  Names? 

□ BACnet  Object  Description? 

Record  Documentation  (7.4.1) 

Before  system  acceptance,  does  the  GSA  have  in  its  possession: 

□ "As-built"  record  drawings? 

□ I/O  Points  Lists? 

□ Documentation  for  any  non-standard  BACnet  objects,  properties,  or  enumerations? 

□ Complete  program  descriptions  of  all  control  and  application  software  per  the  system 
installation  including  English  narratives  of  control/application  programs,  flowcharts  and 
actual  source  code/files? 

Operator  Training  (7.4.2) 

□ Have  the  minimum  number  of  training  hours  and  course  content  been  specified? 


74 


I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 


